🚀 go-pugleaf

>On a related note (vis-a-vis debugging ease) to the branch-and-link
>issue, another peeve I've always had is that no commercially available
>processors (that I know of) make NULL pointer detection easy withou
>serious run-time overhead.  Various OS's try by unmapping the first N
>pages of memory, which works fine until you run into a chip like the
>68030, which supports huge displacements. 

The 68030 is no different from most other processors here; it's
*identical*, of course, to the 68020 in that respect, and even the
earlier 68K's had 16-bit displacements.

Besides, on processors that *don't* have long displacements, the code
that's generated by programmers or compilers generally synthesizes them
with additions, or something such as that, in any case, so the size of
the displacement is irrelevant.

However, if 99 44/100% of all the references through a pointer use
displacements less than about 8K or so - and all the code *I've* seen
backs that assumption up, as very little of it has large displacements -
you can get 99 44/100% coverage.

>Not to mention if the index register pushes the effective address out
>of your protected window, you're hosed.

That's the same issue as the displacement issue; it has nothing to do
with your addressing modes, it has to do with how large the object
pointed to by the pointer in question are.

>If you have a standard base_reg+index_reg+disp format, it would seem to
>me that having the processor check the base register for NULL and
>faulting if it is wouldn't be that hard (or inefficient).

You *don't* always have that format.  And, given my admittedly scanty
knowledge about modern processors, I'm loath to assume that having the
processor do such a check wouldn't be that inefficient; it won't seem
that way to *me* unless at least one processor architect says so....