Re: New Vax - future directions :-)

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2021-07-07 18:16, Mouse wrote:
> > > > > [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.

I don't think it necessarily is that straight forward.

> > (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.

Isn't that the definition of execute only? :-)
If you can't reference it, you can't read it. The CPU can still read it 
(assuming the pages do have read access), so it becomes execute only.

> 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.

Unfortunately, the rules are more complicated than that. Any reference 
through R7 (PC) goes to the I-space, even data.
Consider for example:

    MOV #4711,R0

which in reality is:

    MOV (PC)+,R0
    4711

it's all in the instruction stream, even though the 4711 is in fact an 
access to data.

But had you coded

    MOV (SP)+,R0

it immediately goes to D-space.

But once it goes one level further, it again becomes a D-space. So:

    MOV 4711,R0

is:

    MOV X(PC)+,R0
    4711

where the 4711 relative address is in the I-space, but the PC+4711 would 
then end up in D-space, of course would give an odd address trap here. :-)


> 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.

Right. Which was part of my question why bother with the PDP-11 mode. 
You need AME under VMS to make any use, and then it will work with or 
without actual hardware PDP-11 mode.
And I am not aware of anything besides AME under VMS which did something 
with the PDP-11 compatibility mode.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol