Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New Vax - future directions :-)

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

Home | Main Index | Thread Index | Old Index