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

81–90 of 154 posts

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

#81

Post by Pannoniae »

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?

I would love to, if things actually worked on it! Since everything is HTTPS now and you need TLS1.3 for many things, running very retro things for daily usage is next to impossible.

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

#82

Post by layer8 »

catiopatio wrote: post #28
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"

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.

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

#83

Post by layer8 »

xp84 wrote: post #53
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?

Just like AirPods and AirPods Pro when their 7 cents worth of batteries die! A perfect system.

That will have to change in 2027 with he new EU battery regulation.

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

#84

Post by retrac »

tom_ wrote: post #56
Someone wrote: post #46

Earlier quoted context omitted.

Nitpick: this isn’t standard C (it uses void main , not int main ) Nitpick 2: why ldx #0 txa rts ? I would think lda #0 rts is shorter and faster Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct. I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value.…

I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0. Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll b…

Yes, I compiled with -O3 for maximum speed. That would be an unusual flag choice in most cases.

I just wanted to use 6502 code (so many seem to be able to read it!) with C side by side. x86 would have worked as well. Where the fastest answer would also be the same construct, assuming the dependency on an external routine.

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

#85

Post by ktm5j »

beeburrt wrote: post #59
CalRobert wrote: post #57

Earlier quoted context omitted.

Where does this playfulness persist? I miss it too.

HTTP status code 418?

Haha thanks for this. There are some funny gnu error codes: https://www.gnu.org/software/libc/manual/html_node/Error-Cod...

Including EDIED and EIEIO

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

#86

Post by Max-q »

tom_ wrote: post #56
Someone wrote: post #46

Earlier quoted context omitted.

Nitpick: this isn’t standard C (it uses void main , not int main ) Nitpick 2: why ldx #0 txa rts ? I would think lda #0 rts is shorter and faster Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct. I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value.…

I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0. Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll b…

We did a lot of loop unrolling and self modifying code back in the day, when making demos for the C64. The branch is really expensive. For example, clearing the screen you might use 16 STA adr,x and then add 16 to X before you branch to the loop.

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

#87

Post by tadfisher »

ShadowBanThis01 wrote: post #29
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.

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

That's not even that bad if you have a hot air gun and a reball kit. What's worse is the flash chips having some kind of cryptographic identifier that locks them to the machine, so you couldn't replace the flash if you wanted to.

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

#88

Post by stephen_g »

tom_ wrote: post #77
semi-extrinsic wrote: post #61

Earlier quoted context omitted.

But how quickly though? Do we know the write endurance of the Mac SSDs? I'm not a Mac fanboy by any means. But SSD write endurance has become ridiculous. Even on a cheap-ish read-intensive server-class 1 TB NVMe SSD (~$300) you get around 1 petabyte total write endurance, meaning you can write essentially the entire contents of the disk every day for 5 years and still be within the warranty. That is orders of magnitu…

I've got two Macbook Pros - a 2014 15" (500 GB SSD) and a 2015 13" (1 TB SSD). Both are still going. I can't imagine newer Macs are worse. I'd be more concerned about replacing the battery!

My MacBook Pro (2015, 15 inch) started having some SSD issues earlier this year after a bit more than seven years of heavy use, but it does seem to be partially mechanical because it would mostly happen after it had been in my bag.

Since I bought an M2 Pro to replace it, it hasn’t had the issue I think because I’m just leaving it at home and not flexing or squeezing it much. Perhaps the issue could be fixed permanently and properly with a bit of hot air to re-flow the solder balls.

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

#89

Post by cschmidt »

II2II wrote: post #74
cschmidt wrote: post #68

Earlier quoted context omitted.

I think it was just the enter key to execute the selected text.

You're probably correct. I forgot that Apple labelled the enter key as return on the alphanumeric part of the keyboard and as enter on the numeric keypad. I recall some software (possibly MPW) treating cmd-return as enter. Or something to that effect. It has been about 20 years!

Yes I think you’re right. I was talking about the standalone enter key, or you could also do some modifier and return. It has been a long time

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

#90

Post by Max-q »

TillE wrote: post #54
Aurornis wrote: post #47

Earlier quoted context omitted.

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?

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 software fail on stuff like disabling a button when you have clicked it and the computer is working.

MacOS is on a steady curve to the bottom. It is not alone.

The software bloat and decreasing quality is a serious issue.

Post reply on HN