Re: New Vax - future directions :-)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 3, 2021, at 11:16 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>>> Yes...but do you still have only 16 GPRs?
>> Honestly, I donâ??t see a great deal of need to extend the register file on $
> 
> I don't see any particular need to, either, but it's the kind of thing
> I would like to examine overtly, even if it ends up being discarded.
> 
>>>> The JMP/JSR/RET/... might need a Q counterpart, [...]
>>> And that's another issue with preserving legacy compatability.
>> As I stated before, I think a PSL mode bit to enable â??64-bit modeâ?? is pe$
> 
> Possibly.  I'm not sure whether I prefer that or to just have VAX32
> hardware and VAX64 hardware, with neither running the other's machine
> code.

That would be unfortunate, especially if the majority of the heavy-lifting finding the bit in the insn encoding to indicate Q mode.  Most 32-bit software would simply work by virtual of not using the Q variants.  And because the PSL part of the context that is saved/restored across the user-kernel boundary, putting the “64-bit mode” bit there would essentially complete the puzzle for 32-bit “VAX classic userland” running with a “VAX-64” kernel.

Anyway, it seems otherwise “very weird” to have to explicitly JSRQ or whatever … feels like the “long calls” of old back in the less-than-32-bit x86 era.

>>>> Kernel; the hardware structures (SCB, PCB, ...) must all be
>>>> expanded.  Memory management changed (but the existing leave much
>>>> to wish for anyway).  All this is probably a quite simple update to
>>>> the architecture.
>>> All true...but it leaves me asking how much you can change and still
>>> preserve the elegance that makes a VAX feel like a VAX.
>> I think you can preserve quite a lot.  Honestly, the standard â??VAX-32â?? V$
> 
> It is.  The only respect in which I think it's elegant is that it's
> very simple.

The way the 32-bit VM works is pretty limiting.  Userland gets 2G of total address space, and the kernel only gets 1G. I mean, yah, it’s really simple, but I think it forces some unfortunate trade-offs.

> Personally, I feel no need for executive or supervisor mode.
> 
>> As for the PCB, I would just do away with P{0,1}{B,L}R and replace them with$
> 
> I would do something else, certainly.  I'm not competent to comment on
> the Alpha model, since I don't know enough about it.

TL;DR version — Alpha *hardware* is a basic sw-managed TLB system (with separate I- and D- TLBs), but the Alpha PALcode provides the illusion of a hardware table-walker with a unified 3-level table (i.e. each process’s table just also map the kernel).  There are some tricks that make the PALcode TLB-miss handler faster (like the recursive “virtual page table” mapping), but none of those are applicable here… My assumption is that any extended VAX-64 would implement a table-walker in hardware.

The Alpha also provides for a fixed-offset identity mapping of the physical address space in KSEG9, which is *insanely* convenient.

> As for memory, I don't know what you consider "reasonable".  But the
> obvious practical answer is "for the same reason I run amd64 rather
> than i386 even on hardware with <1G of RAM" and there's also the simple
> "hack value" answer.

I’d be willing to state “64MB minimum for VAX-64” based on mu experience with Alpha.

-- thorpej