Comment by msla
6 years ago
Everyone talks about the macro abuse, nobody talks about the memory management abuse:
https://www.in-ulm.de/~mascheck/bourne/segv.html
> In comp.arch, 05/97, <5m2mu4$guf$1@murrow.corp.sgi.com>, John Mashey writes:
> For speed, Steve B had used a clever trick of using a memory arena without checking for the end, but placing it so that running off the end would cause a memory fault, which the shell then trapped, allocated more memory, then returned to the instruction that caused the trap and continued. The MC68000 (in order to go fast) had an exception model that broke this (among other things) and caused some grief to a whole generation of people porting UNIX to 68Ks in the early 1980s.
To be fair, that's not exactly a horrible perversion, relying on the existence of memory protection. Hell, that's precisely how stack grows dynamically on Windows: there is a guard page at the bottom, when it's touched, the kernel allocates it and marks the page below it as the new guard page. The downside is that stack allocations larger than 4 K have to manually probe memory to trigger this behaviour, that's what _stkchk from CRT does.
Most of such low-level hacks are nowadays reserved exclusively for runtime implementations, probably for the better.
The early 68k machines had memory protection, they just couldn't resume the instruction that triggered it, it wasn't until the 68010 that this was fixed. You can also see evidence of this in early 68k C compilers, the function entry code would have a dummy instruction to probe the end of the area on the stack that was needed to hold any local variables.
Nit, but it's _chkstk.
> memory fault
That reminds me of how virtual memory works.