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

111–120 of 154 posts

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

#111

Post by Mawr »

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.

Binary size, yes, since that's just sequentially reading bytes from an SSD. What sucks about modern software is input latency and overall responsiveness.

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

#112

Post by [deleted] »

Wowfunhappy wrote: post #32
13of40 wrote: post #4

"Call me paranoid but finding '/*' inside this comment makes me suspicious" That, Sir, is none of your business.

...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.

[deleted]

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

#113

Post by astrange »

LoganDark wrote: post #71
smoldesu wrote: post #67

Earlier quoted context omitted.

I don't think that feature is exclusive to Apple Silicon, or Macs.

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.

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

#114

Post by [deleted] »

hgs3 wrote: post #8
jonhohle wrote: post #2

I miss this kind of playfulness in computing. When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kit…

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

[deleted]

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

#115

Post by notbeuller »

CalRobert wrote: post #57
jonhohle wrote: post #2

I miss this kind of playfulness in computing. When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kit…

Where does this playfulness persist? I miss it too.

On the other hand, I despise the mock playfulness exhibited by, eg, Slack. It’s such a frustrating environment for me - I feel like it’s not-so-subtle attempts at promoting engagement over presenting the content fill me with rage. I want my tools to fade into the background.

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

#116

Post by retrocryptid »

retrac wrote: post #16
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.

Your optimizing compiler today will actually optimize. LLVM was recently ported to the 6502 (yes, really) [1]. An example: void outchar (char c) { c = c | 0x80; asm volatile ("jsr $fbfd\n" : : "a" (c): "a"); } void outstr (char* str) { while (*str != 0) outchar(*str++); } void main () { outstr("Hello, world!\n"); } That is compiled to this: lda #$c8 ; ASCII H | 0x80 jsr $fbfd lda #$e5 ; ASCII e | 0x80 jsr $fbfd ... U…

Well... I mean... if you want inverse video.

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

#117

Post by sp332 »

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!

The newer ones could be worse as they move to smaller process nodes and store more bits per cell. That said, the controller logic is improving, and larger capacities mean more room for wear leveling, so it shouldn't be too bad.

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

#118

Post by djur »

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…

I see this sentiment again and again, but the Windows 95 experience I remember included frequent spinning hourglasses, blue screens of death from faulty drivers, everything grinding to a halt when memory is near exhaustion or files are being copied between disks, tons of third party applications (and even Microsoft applications, like Office) that disregarded the Windows UI standards, constantly having to run CHKDSK and defrag, not to mention malware/virus vulnerability...

Latency when the system is under low load was definitely better, although a big contributor to that is changes in input and display hardware. But otherwise I'd much rather have today's "bloated" experience over the real world of the '90s.

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

#119

Post by WicWacWok »

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?

Is it accessible enough it can be soldered-out, or is this one of those effectively-permanent things?

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

#120

Post by mysterymath »

messe wrote: post #95
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.…

> Nitpick: this isn’t standard C (it uses void main, not int main) You know what, I'm gonna nitpick that nitpick: void main() is fully allowed on a freestanding target, which is still standard C. Given the C standards historically generous interpretation of undefined behaviour and other miscellany, I think it's a reasonable interpretation of the standard to pretend that a target that allows something other than int m…

Yep, llvm-mos-sdk is explicitly freestanding; the libc functions in the SDK follow the hosted C standard, but they don't add up to a hosted implementation. The only known C99 non-compliance is the lack of floating point support, which is actively being worked on.
Post reply on HN