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

61–70 of 154 posts

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

#61

Post by semi-extrinsic »

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?

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 magnitude beyond what any consumer is going to subject their disk to.

There is always a possibility that a part of the computer will fail. But if the SSD is less likely to fail than any other random IC on the motherboard, having it soldered on doesn't factor significantly into the failure statistics.

Of course it's super annoying that you can't upgrade the disk size, but that's another point.

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

#62

Post by tyg13 »

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…

You're correct, although I'm fairly sure dereferencing a `void*` is a compile error on all but the most ancient and non-conforming compilers. I'm not even sure what it _could_ compile to, given that `void` has no size.

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

#63

Post by jonhohle »

mastry wrote: post #52
omoikane wrote: post #15

Earlier quoted context omitted.

> picture of a cat I couldn't find this elusive picture of a cat on archive.org, but I found this dog instead: https://web.archive.org/web/20030113144310/https://www.amazo... June 2016 appears to be when Amazon adopted the current error pages with the large dog images. https://web.archive.org/web/20160612232820/http://www.amazon...

Maybe this is it? http://telcontar.net/Screenshots/worldwidewonk/Amazon-404-eh...

That’s the one!

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

#64

Post by chongli »

MatthiasPortzel wrote: post #36
retrac wrote: post #16

Earlier quoted context omitted.

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…

I understand your point, but LLVM-MOS is a bad example. You gain LLVM’s language optimizations, as you point out. But LLVM’s assumed architecture is so different from the 6502 that lowering the code to assembly introduces many superfluous instructions. (As an example, the 6502 has one general purpose register, but LLVM works best with many registers. So LLVM-MOS creates 16 virtual registers in the first page of memor…

So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used.

Isn’t this actually good practice on the 6502? The processor treats the first page of memory (called the zero page) differently. Instructions that address the zero page are shorter because they leave out the most significant byte. Addressing any other page requires that extra byte for the MSB.

Furthermore, instructions which accept a zero page address typically complete one cycle faster than absolute addressed instructions, and typically only one cycle slower than immediate addressed instructions.

So if you can keep as much of your memory accesses within the zero page as possible, your code will run a lot faster. It would seem to me that treating the zero page as a table of virtual registers is a great way to do that because you can bring all your register colouring machinery to bear on the problem.

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

#65

Post by tredre3 »

MatthiasPortzel wrote: post #36
retrac wrote: post #16

Earlier quoted context omitted.

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…

I understand your point, but LLVM-MOS is a bad example. You gain LLVM’s language optimizations, as you point out. But LLVM’s assumed architecture is so different from the 6502 that lowering the code to assembly introduces many superfluous instructions. (As an example, the 6502 has one general purpose register, but LLVM works best with many registers. So LLVM-MOS creates 16 virtual registers in the first page of memor…

I understand your point but the beginning of the zero page is almost always used as virtual registers by regular hand-rolled 6502 applications. So it's pretty normal for LLVM to do the same, it's not an example of LLVM doing something weird.

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

#66

Post by jonhohle »

omoikane wrote: post #15
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…

> picture of a cat I couldn't find this elusive picture of a cat on archive.org, but I found this dog instead: https://web.archive.org/web/20030113144310/https://www.amazo... June 2016 appears to be when Amazon adopted the current error pages with the large dog images. https://web.archive.org/web/20160612232820/http://www.amazon...

I misremembered the dog, it looks like they first replaced it with a ?⃝ icon. A later snapshot has the image name[0] but not the image[1].

mastry found a screenshot of the image in his sibling reply.

0 - http://g-ecx.images-amazon.com/images/G/01/x-locale/common/k...

1 - https://web.archive.org/web/20071030172825/http://www.amazon...

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

#67

Post by smoldesu »

LoganDark wrote: post #30
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"

This is even more true today, because Apple Silicon Macs are able to store twice the amount of information in the same amount of memory, meaning that a paltry 8GB configuration can store 16GB of FizzBuzz boilerplate, 4 Google Chrome tabs, or 20% of the average node_modules.

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

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

#68

Post by cschmidt »

II2II wrote: post #33

Tangential to the content of the page: I really enjoyed how many MPW utilities generated output, including error messages, in the form of commands. Your terminal was an editor buffer, so you could cursor up (or click) on the appropriate line then press something like cmd-enter to pull up the file in question (among other things).

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

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

#70

Post by zer8k »

tyg13 wrote: post #62
zer8k wrote: post #43

Earlier quoted context omitted.

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…

You're correct, although I'm fairly sure dereferencing a `void*` is a compile error on all but the most ancient and non-conforming compilers. I'm not even sure what it _could_ compile to, given that `void` has no size.

Yes most modern C compilers will stop you from dereferencing a void pointer. Still, I couldn't help but bring up what can happen. Since I didn't witness it I can only assume 3 mile island was someone dereferencing a void pointer and it was easier to explain with a nuclear meltdown.
Post reply on HN