Re: New Vax - future directions :-)

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

Den 2021-07-05 kl. 20:29, skrev Johnny Billquist:
> Hi.
>
> On 2021-07-05 19:54, Anders Magnusson wrote:
> > Den 2021-07-05 kl. 19:12, skrev Johnny Billquist:
> > > On 2021-07-03 15:46, Anders Magnusson wrote:
> > > > So, some thought about expanding the Vax architecture.
> > >
> > > Interesting topic, yes...
> > >
> > > > 64-bit:
> > > > For userspace; the vax architecture itself leave the door open for 
> > > > expanding the word size.   The instructions are all defined to use 
> > > > only the part of a register it needs, so adding a bunch of 'Q' 
> > > > instructions are a no-brainer. Argument reference will work as before.
> > >
> > > Indeed. There are even some instructions that already exists in Q 
> > > format. However, I am unclear what actually happens if you do a
> > >
> > > CLRQ R0
> > >
> > > does it clear R0 and R1, or just R0?
> > Both.  The two Q instructions that exist would do the same on memory 
> > but not on registers.
>
> CLRQ 0
>
> is obvious. It clears all the bytes at address 0 to 7.
>
> CLRQ R0
>
> is what I am uncertain about. And your answer just confused me. :-)
Yep, now when I read it it seems quite cryptic :-)
What I meant was: in 64-bit mode CLRQ would do the same as in 32-bit 
mode when referring to memory, but not to registers :-)
> > > Also, you would probably want to add a new addressing mode, for quad 
> > > offset. Which would be rather tricky to do...
> > Quad addressing mode already exist, you know? :-)
>
> No, I didn't know (well, direct arguments are just addresses or 
> registers, size is implied by the instruction, and not by the 
> addressing mode). But I suspect you were just having a joke on me 
> since I did mean it for displacement... :-)
:-)

> > There are as I can tell only two things in the addressing modes that 
> > are affected;
> > - Displacement mode > longword. I don't think this can ever be a 
> > problem, a displacement larger than 32 bits could be written in 
> > numerous other ways.
>
> That I'm not so sure about. But anyway, it is what I was thinking of.
> If we go with 64 bits, it would be to accommodate large programs and 
> data, I assume. And then I can easily see that the distance to 
> something you refer to is going to be larger than 32 bits sometimes.
Yep, the distance, but not as a displacement.  Having a struct larger 
than 2G?  Quite uncommon.
> But sure, you could just go medieval, and calculate all addresses 
> explicitly before referencing, so I guess you could live without it, 
> but it could be annoying.
You would most likely not hand-code it anyway :-)  And if you do - well, 
know what you are doing :-)

> > - Absolute addressing.  This would solve itself if a mode bit is used 
> > as thorpej suggested.
>
> Absolute addressing either 32 or 64 bits based on mode - sure.
>
> > Actually, the more I think about it, the more compelling do a mode 
> > bit look like :-)  It worked well for PDP11 code, so why not for 
> > VAX64? :-)
>
> Definitely doable.
>
> But I am getting lost in all the windings of this extension.
>
> For the PDP-11, DEC made it easy by only implementing the simple user 
> mode aspects of the PDP-11 on the VAX, and skipping some parts that 
> would have complicated stuff.
>
> Not sure if you want to do some kind of a limited variant VAX for the 
> XVAX compatibility mode. But maybe I'm just thinking of this all from 
> the wrong angle at the moment.
>
> If I start with an XVAX, and don't bother being that compatible with 
> the VAX, we can certainly implement a VAX compatibility mode on such a 
> machine.
>
> But then we have much more freedom as well, and can indeed change 
> addressing modes, instructions and registers any way we want to.
>
> > > > Multiprocessor:
> > > > Vax have had multiprocessor support since ~forever, but it may be a 
> > > > good idea to revise the interlock instructions.
> > > > There are only 7 of them and a few more would be nice.
> > > > Having it in a FPGA would make it simple to clone up many Vaxen in 
> > > > the same cheap chip :-)
> > >
> > > Agreed. The interlock instruction repertoire have always seemed a 
> > > bit strange to me.
> > > And unfortunately, when I tried to make efficient use of it in 
> > > NetBSD many years ago, it turned out to be pretty impossible. NetBSD 
> > > essentially requires the CAS instruction, so adding that would be a 
> > > big win.
> > Basically everyone needs something else than the queue interlock 
> > instructions... :-)
>
> It's not just that.
> The BBSSI and BBCCI are perfectly fine for any kind of mutex. But it 
> still ended up a mess when I wanted to use them.
Biggest problem with them are that they are bitfield instructions, hence 
tedious to evaluate.

> The ADAWI is a bit too limited, as we all know.
>
> And the queue instructions are just too specialized to be used in 
> something that is machine independent.
>
> > > > - AND.  Vax have BIC instead, but that (almost) always require a 
> > > > complement as well.
> > >
> > > Funny. It's the same on the PDP-11, but quite honestly, I actually 
> > > find it way more useful to have BIC than AND. When I have AND, I 
> > > need to do complements a lot, because in the majority of all cases, 
> > > what I am interested in is clearing bits out.
> > >
> > > If you just want to check if a bit is set, then you use BIT anyway, 
> > > which is doing an AND, but it just sets the condition codes.
> > In a C compiler you only have AND, so when translated it usually ends 
> > up with a COMPL as well.
>
> A good C compiler sees that you are doing a masking and clearing, and 
> figures out it can all be reduced to a BIC. :-)
> Because that's what you see most of the time in the C code as well.
Well, c = a & b; is the most common, can cannot be reduced...
> > But AND wouldn't harm anything, in my implementation it would just be 
> > a one-step microassembler entry, just like BIC.
>
> Agreed. AND would not harm anything. So add it. :-)
-- R