Comment by WalterBright | Hacker News Reader

Comment by WalterBright | Hacker News Reader

I used OS/2 in order to develop Zortech C++ further. Its great advantage was protected mode. When there were memory bugs, instead of scrambling my hard disk it would seg fault. I'd get everything working perfectly on OS/2. Then, I'd port it to Rational's 286 DOS Extender, which also operated in protected mode. This would purge all the bugs in the compiler related to the mixed 16 bit memory model. Then the last step was to port it to real mode DOS.

OS/2 saved me an enormous amount of debugging time.

I always laugh when people complain about null pointer seg faults. Those are a feature, not a bug. Finding bugs in your code immediately, rather than a few miles further down the road, is a great attribute.

Writing through a null pointer in real mode DOS meant overwriting the interrupt vector table. Probably the worst CPU architectural mistake of all time is locating that table at address 0. If you were lucky, DOS would just freeze up, and you could reboot it. If you were unlucky, it would scramble your hard disk, and you'd have to re-install the operating system and all your files.

The ROMs (i.e. boot address) should have been located at address 0, and the interrupt table at FFFFF.

> Probably the worst CPU architectural mistake of all time is locating that table at address 0.

That’s not something unique to x86; eg. the PDP-11 also had its interrupt vector table starting at address 0. This only became a real problem when languages that treated address 0 as a sentinel value became popular.

Ironically, C originally used 0 as a sentinel address precisely because it could not hold a real value, because that's where the interrupt table was.

Amazing piece of trivia.

C did not say 0 was the sentinel address. Most implementations had it as 0, but it could be any address, and K&R (first edition - highly recommended) had a table of what NULL was on various platforms - most were 0, but not all. In C++98 0 was the sentinel address, resulting in the compiler having to guess if you really meant 0 or whatever NULL really was when you have 0 in the code if NULL wasn't 0. C++11 introduced nullptr which is implementation defined.

> resulting in the compiler having to guess if you really meant 0 or whatever NULL

IIRC you had to cast 0 to a pointer, which made it a null pointer as distinct from arithmetic zero. Or am I confusing myself... It's been a while.

0 is a valid pointer on some systems. So 0 could be address 0 or whatever NULL was (0xeeeeeee or something equally weird)

Nothing got defined until much later, it's just that the early implementation of C used a 0, because it was not an usable address and they didn't want to burn any usable address space (of which there was only 56k on the PDP-11).

> Probably the worst CPU architectural mistake of all time is locating that table at address 0.

I don't know if it persisted into 16-bit era CPUs & OSs, but early on the bottom of the memory map was faster to access, so things like interrupt tables¹ were often located there. The 6502 family even had specific load and save instructions for zero-page so not only was the actual operation faster once read & decoded, it took two bytes not three to store so was read faster² and took less space.

--

[1] you generally want the response to an interrupt to be as fast as possible, shaving a few clock cycles off could be pretty significant

[2] so a double time saving

It was only faster because of the shorter encoding, something that doesn't matter when the CPU itself is generating the address like on an interrupt. On the 6502, there is a single vector for maskable interrupts, and another for NMI, both of them at the top end of address space.

The 8086/8088 microcode that handled interrupts used a special "segment 0" to provide the address, I don't think it would have been difficult to have some other hardwired value instead of 0. And on later x86 chips there is an actual register for it (IDTR) that can be changed by software - even in real mode, though for reason of backwards compatibility this wasn't usually done.

The 6502's interrupt vector is located at the _top_ of the memory map, but the reasoning is the same; you can simplify address decoding and shave clock cycles.

Hello. What happened to Zortech ? Any chance that Zortech C++ for OS/2 can be open sourced ?

Reply on news.ycombinator.com