Re: New Vax - future directions :-)

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

Den 2021-07-04 kl. 02:33, skrev Jason Thorpe:
> > > 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” VM layout is pretty limiting; I don’t consider it “elegant” at all.  Adopt the Alpha OSF/1 style address map that gives you distinct “user” and “kernel” segments, as well as a large direct-mapped segment, and if you want Executive and Supervisor modes, add a couple of PTE bits to enable those restrictions in the User segment.
>
> As for the PCB, I would just do away with P{0,1}{B,L}R and replace them with a single PTBR that points to a 3-level table like the Alpha OSF/1 PALcode uses.  Presumably, a VAX-64 system would have a reasonable amount of memory connected to it (I mean, otherwise why would you bother with a 64-bit mode?), so just use 8K page size when in 64-bit mode like Alpha uses.  Since presumably VAX-64 would have a HW table-walker, you don’t need the VPTBR that Alpha has (there is really only there for the PALcode to use).
Agreed.  No reason to make a 64-bit VM system in any way be similar to 
the old one.
Better to make it match the requirements of today.  The Alpha VM might 
be a good one to look at, yes.

> > > Multiprocessor: [...]
> > I'd say, be careful to not design MP out, but "first make it work, then
> > make it better".
> A compare-and-swap instruction would pretty much cover anything that needs to be done.  Essentially all of the synchronization primitives used by the NetBSD kernel are built upon it.  Now, it MIGHT be easier to implement LDx_L / STx_L in the hardware (but maybe not when you consider peripherals that can access main memory), but it doesn’t seem very VAX-like … whereas something like a CASL3 that updates Z to indicate success/failure does seem pretty VAX-like :-)
:-)  I tend to really agree with you here.  Also, since all other 
instructions work this way, marginally extra hardware would be needed.
That would be three instructions,  like:

    CASBI    mb,rb,rb
    CASWI   mw,rw,rw
    CASLI    ml,rl,rl


> > You might consider scrapping bitfield support entirely.  If you go with
> > bit-addressible memory, you don't need it anyway except possibly to
> > trim-to-width as part of the load.  (There's a certain amount of
> > inconsistency in that the VAX is not, in general, a load/store
> > architecture, but when it comes to bitfields it is.)
> IIRC, the compiler makes pretty good use of the bitfield insns, so I think you pretty much need to keep them.
No reason to remove them at all, but they are inefficient. Currently the 
are about 30 microassembler steps due to the complicated syntax.
Having them in pure hardware would make the faster, but it takes much 
hardware.

Here is the microassembler bitfield extraction subroutine just to give a 
hint.  Note that all common logical functions are only one microinstruction.

#
# extract bitfield based on (pos,size,base) in (arg1,arg2,argp0)
# return field in argd0, return addr in argp1. Trashes arg1+arg3.
#
bfield:
# sanity: size > 32?
        and 0 0         argd0                   # 177
        minus arg2 21   arg3                    # 178
        and arg3 arg3   nncond resopflt         # 179
        and arg2 arg2   zcond goto bf_done      # 180
# Check whether read from mem or reg?
        shr argp0 1E    argd0                   # 181
        minus argd0 3   argd0 nzcond goto bf_mem        # 182
# Ok, get from reg.
        minus arg1 20   nncond resopflt # resopflt if pos > 31
        plus argp0 0    crn             # 59 set cur reg num
        plus crv 0      argd0           # 60 move val to dest
        plus argp0 1    crn             # if two regs
        plus crv 0      arg3 goto bf_common     # 60 move val to dest
#       and arg1 arg1   goto bf_common  # just jump
bf_mem:
# Normalize first
        asr arg1 3      arg3            # 189 get byte offset
        plus argp0 arg3 argd0           # 190 argp0 == byte offset
        and argd0 3     arg3            # 191 arg3 == byte offset in 
longword
        and arg1 7      arg1            # 192 arg1 == bit offset
        shl arg3 3      arg3            # 193 make bit offset
        plus arg3 arg1  arg1            # 194 pos == bit offset in longword
        bic 3 argd0     argp0           # 195 clear byte offset bits in ptr
        plus argp0 0    cpuaddr rmem    # 196 fetch low long
        plus rmemdat 0  argd0           # 197 dat now in argd0
        plus argp0 4    cpuaddr rmem    # 198 next long
        plus rmemdat 0  arg3            # 199 XXX should check if needed
bf_common:
# create long in argd0
        shr argd0 arg1  argd0           # 200 right-adjust low bits
        minus 20 arg1   arg1            # 201
        shl arg3 arg1   arg3            # 202
        bis arg3 argd0  argd0           # 203

bf_done:
        plus argp1 0    arg3            # 204


-- R