Re: New Vax - future directions :-)

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

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. :-)

If it indeed clears R0 and R1, then we have a bit of a problem, since if 
we were to extend the VAX to 64 bits, then I would think people expect 
R0 to be capable of holding a quad, and thus CLRQ R0 would only clear R0.

Clearly my PDP-11 roots are shining through here. On the PDP-11, there 
are some instructions that deals with 32-bit values, and then two 
registers are linked together to deal with it. I am wondering if the VAX 
did the same for 64-bit things...

Damn! It feels like I should know this, but it's been so long since I 
did anything with VAXen that I've almost forgotten it all.

Ah. And I just looked and found the right place in the processor 
handbook. They do indeed concatenate two registers.

So it becomes ambiguous what a CLRQ R0 would do now. Clear just R0, 
since it's not 64 bits... But traditionally people would have expected 
it to clear R0 and R1.

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

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.

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

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.

> 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. :-)

  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