Re: UVM and the NULL page

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Depends on the architecture.  For example, on the VAX, I would say
>> c0000000 and e0000000 would be prime candidates, because the high
>> quarter of the possible address space is permanently reserved.
> Then the bit encoding for null should obviously be 0xdeadbeef :-)

Indeed!  I don't know why I didn't think of that.

> (it is better, i.e., more likely for it to fault if used by accident
> even with a large offset, if it's unaligned)

After a fashion.  There are very few things on the VAX for which
alignment affects more than performance, and most of them are
kernel-mode-only.  ADAWI, the queue instructions, and the vector
instructions are, I think, about it.  (In kernel mode there are a bunch
more.  SBR, P0BR, P1BR, SCBB, PCBB, the RPB (if used), VSAR, all have
alignment restrictions.)

> If you don't have a hardware-reserved address, then you're
> designating a reserved region yourself (regardless of what it is) and
> relying on the VM system to not map it.  At which point zero is as
> good (or bad) as anything else.

Except that some compatability things (WINE?) actuaslly want address
zero to be mapped; isn't that where we came in on this discussion?

Of course, those too are generally arch-specific.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B