Re: New Vax - future directions :-)

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

On 2021-07-08 04:53, Mouse wrote:
> > > > I don't suppose you'd happen to know where I might be able to get
> > > > hold of that 2.11 binary?
> > > It's in the standard 2.11BSD distribution.
>
> Okay, I'll have a look-see and see if I can find that.

Let me know otherwise. But it's a fairly small amount of code which just 
catches the neccesary RT-11 EMT system calls and rework them to do the 
right thing under 2.11BSD, and then load the actual RT-11 binary.
And the RT-11 binary is just a binary blob in there.

> > Actually, getting this running under NetBSD/vax would be a rather
> > interesting, but complicated exercise no matter what.
>
> > If we ignore the whole problem that the PDP-11 compatibility mode
> > does not include split I/D space to start with, [...]
>
> That's fixable, since I'll be running on an emulated VAX to begin with.

I'd be interested in hearing you you will fix that. :-)

> But, really, no worse than what I did for the SPARC emulation (which
> emulates a SPARC userland, entirely in software), crossed with a tiny
> bit of VAX kernel hackery to handle traps from PDP-11 mode.

I'll believe that when I see it. :-)

> In fact, I think the first version would run as a normal NetBSD/vax
> executable, except that it's linked such that the first 128K of the
> address space is empty.  The PDP-11 then runs there.  Most exceptions
> just bounce off the kernel back into userland as fast as feasible,
> letting the VAX userland process do whatever it needs to to emulate
> things like syscalls.  As I read the PDP-11 compatibility mode chapter
> of the VARM, VAX user mode should be able to REI directly into PDP-11
> mode without needing privilege, so userland can switch back to PDP-11
> mode anytime.

Right. That's how I expect you'd want to do it. Have the 2.11BSD 
compatibility mode being in the same executable process, but mapped 
higher up in memory.
And yes, you should be able to switch back to PDP-11 mode directly.

With NetBSD, I would expect you'd setup a signal handler or three to 
just catch the kind of exceptions that would happen when it traps out of 
PDP-11 mode. You'd probably want to define a few new signals for this?

> A little kernel help would be needed, but not much; between
> mmap's MAP_FIXED and siglongjmp out of signal handlers, I think the
> only new kernel code needed is recognizing the PDP-11 mode bit in the
> PSL in trap handlers and punting things back to (VAX) userland.

I would possibly want a few different signals for different traps out 
from emulation mode. Then it should be somewhat straight forward, except 
of course you need to get the PC and other relevant registers from the 
trap in order to be able to check what happened, and for system calls 
get the arguments out. Arguments for RT-11 calls seems to be pushed on 
the stack, and the PDP-11 stack is in VAX R6 (although this shouldn't 
matter, since this should be handled by the 2.11BSD Zork code anyway).

Of course, you could just have one handler for everything, and then dig 
out the reason from there. With some aid from the NetBSD kernel, that 
should also be possible.

And then you need to do the 2.11BSD signal handling inside this 
environment, to allow it to catch the RT-11 system calls.

  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