Re: New Vax - future directions :-)

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

>>>> [VAX PDP-11 emulation mode]
>>> No split I/D space, [...]
>> So I guess we have another few feature requests, then... :)
> This might be extremely hard, since it's a feature that comes from
> the design of the PDP-11 MMU.  The VAX MMU is very different, and
> don't allow this.  (Allow might be the wrong word here - it's just
> not possible.)

Yes.  It doesn't have any way to represent it.

However, it wouldn't be all that hard to add; vide infra.

> (Anyone talked about execute-only protection of memory... The PDP-11
> have it. :-) )

Does it?  Split I/D isn't really execute-only protection in the usual
sense.  It's not that code memory is protected against data accesses so
much as it is that data accesses have no way to name it and thus
inherently can't even try to access it.

It wouldn't be hard to, for example, define a variant of PDP-11
compatability mode for which instruction fetches came from
00010000-0001ffff while data accesses used 00000000-0000ffff.  The
underlying VAX OS could then map those to the same physical memory when
and as appropriate.

But running something like 2.11BSD would require more than just classic
VAX compatability mode, because it's more than just user mode.  Not
that emulating the OS is impossible.  I have an emulator for SPARC32
that does exactly that - it's userland-only and anything that would
trap to the OS on real hardware is handled by the emulator.  But it's a
very different thing from just emulating the hardware.

/~\ 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