Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some of the error messages produced by Apple's MPW C compiler (2006)

cs.cmu.edu

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#121

Post by LoganDark »

astrange wrote: post #113
LoganDark wrote: post #71

Earlier quoted context omitted.

It's a joke (clearly not a very good one) based on my experience that when Apple first offered only 8GB of RAM on the first ASi Macs, everyone's response was that Apple Silicon can simply store more data in the same amount of memory or something. Back when I used macOS on Intel, 16GB was relatively comfortable, but I can't imagine that switching to ARM would magically halve memory requirements. (Yes, the Intel Mac ha…

The AS memory compression is better as it's hardware accelerated. IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead, but I don't remember the details.

I think ASi Macs also use swap by default now, because the SSDs are so fast that it's actually a tenable solution to memory pressure. My Intel Mac never had any swap.

> IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead

Yeah... one of the reasons why I dislike it.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#122

Post by LoganDark »

zzo38computer wrote: post #103
billforsternz wrote: post #101

Earlier quoted context omitted.

The fact that you can't do this with new fangled languages is one of the reasons I don't use new fangled languages

That and other things I dislike about many of the new fangled languages.

I prefer using completely unfangled languages, thank you very much.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#123

Post by LoganDark »

arcanemachiner wrote: post #42
Wowfunhappy wrote: post #32

Earlier quoted context omitted.

...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.

How about explicit depth levels, specified by asterisk count? e.g. '/*' and '*/' would match each other, '/**' and '**/' would match, and so on. That way, you would have full control of the depth of the comments, removing other comments wouldn't break the inner comments, etc. I do run into the same issue you're describing, so I think there's value in the idea.

Like Lua, where comments can be delimited by `--[==[`..`]==]`, where the number of equals signs can be anything but has to match in order for the comment to actually close?

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#124

Post by grishka »

AnonC wrote: post #21

> "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer" Ah, the old times when one could purchase a RAM upgrade or upgrade RAM after buying a computer. Now this would be: "Symbol table full - fatal heap error; please go buy a new Mac with more RAM"

Not really. Classic Mac OS didn't support virtual memory so everything had to fit in RAM unless a program itself offloaded data it's not currently using to the disk. Modern OSes, however, all support swapping. Your compilation would continue, just much slower. To truly "run out of memory" on a modern computer, you have to fill up both the RAM and the disk.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#125

Post by tdiff »

zer8k wrote: post #43
jimmaswell wrote: post #37

Earlier quoted context omitted.

Not much of a C programmer, what's the context around void* being a big deal?

Void pointers refer to anything and nothing. They are everything and all encompassing. What is pointed to by the void pointer could be what you want or it could be another universe. Dereferencing a void pointer has no meaning. The compiler can do anything it wants because it doesn't know how to interpret the memory. It could give you the correct thing, it could warp a civilization in from a distant planet, or it coul…

Has any civilization been warped in already?

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#126

Post by ShadowBanThis01 »

LeoPanthera wrote: post #92
ShadowBanThis01 wrote: post #29

Earlier quoted context omitted.

The soldered-in SSD is worse, though. The SSD WILL wear out, so then you get to throw away your Mac?

> The SSD WILL wear out This is by no means certain, certainly not enough to SHOUT about. Modern SSDs have lifetimes that make them impractical to literally wear out, short of some kind of fault.

OK BUDDY YOUR WELL-CITED CLAIMS ARE NOTED.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#127

Post by bondolo »

I used this compiler for years and eventually came to be able to “decompile” the 68k object code it produced back to C code in my head on the fly unless the function was too large. Using MacNosy I could rebuild the C source for an app in usually only a couple of hours. I had a script that converted a MacNosy file of an app into an assembler file and rsrc file and I could translate functions to C one at a time while having a buildable app equivalent to the original. I originally used the tools for hacking games but sometimes used it to fix bugs.

The MPW C compiler code generation was so predictable in part because of the symmetry of the 68k instruction set. They wrote a simple compiler and it worked. For the most part effort was spent elsewhere. Since you could reasonably predict what code would be generated if you were unhappy with the code generation you fixed the source. I like that the javac compiler has a similar ethos, With similar effect. Once you know the patterns to use you can generate fairly close to optimal byte code.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#128

Post by NikkiA »

Max-q wrote: post #90
TillE wrote: post #54

Earlier quoted context omitted.

Binary size on a desktop OS is almost totally irrelevant in practice. Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't. People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.

Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive. Bloat making software bigger will in many cases also make it slower. Also, the UX on Windows 95 was consistent and easy to learn. Now, much softwa…

Word 95 was utter bloatware compared to 2.0c though

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#129

Post by hulitu »

Aurornis wrote: post #47
hgs3 wrote: post #8

Earlier quoted context omitted.

> The compiler is 324k in size Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.

There’s nothing stopping anyone from going back and using all of that old software exclusively. For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?

> There’s nothing stopping anyone from going back and using all of that old software exclusively.

You need to search for it on old ftp sites.

> For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?

The compilers have "evolved". Compiling old code is challenging, to say the least. I do compile old programs when the new seem to explode: xpdf, xsnow.

Compiling old compilers is impossible because they rely on ancient kernel headers.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#130

Post by Dylan16807 »

layer8 wrote: post #82
catiopatio wrote: post #28

Earlier quoted context omitted.

I understand the arguments for unified RAM on a SoC, but it’s still a shame; even the new Mac Pro doesn’t have RAM slots.

They could still allow adding more RAM that would just be slightly slower.

They would need to extend the slots from the existing ram, which would slow it down even when empty, or they would need to use up a lot of silicon adding more memory channels. It really does make sense to solder on RAM for best performance. Though alternative sockets like CAMM might help in the future.

But you can't do a trade-in, the RAM they sell is extremely overpriced, and as mentioned elsewhere there's no excuse for the SSD.

Post reply on HN