Re: New Vax - future directions :-)

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

On 2021-07-05 21:39, Anders Magnusson wrote:
> 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 :-)

It was. And I'm not sure your answer here made it any clearer. But 
reading the processor handbook resolved it for me anyway.

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

Ah. I *think* I understand what you meant now, but you might just have 
confused me as well. But it don't matter.

So far, I had been thinking of being binary compatible with VAX32 for 
the VAX64, but I realized that I maybe should drop that idea.

Looking at it the same way as the PDP-11 compatibility was done in VAX32 
is a different angle, essentially resulting in a machine where we can do 
anything we want in a different (better) way if we want to.

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

You're talking to someone who still lives and breathes in a 16-bit 
address space on a daily basis...
Who needs 32 bit offsets anyway? :-)

Or, to put it another way - you can bet some crazy people are doing such 
things already.

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

Certainly. But as a user of the instruction set, if I were to implement 
a mutex, that's what I'd use.
Except when I tried switching to this in NetBSD, it was a can of worms 
and a rabbit hole that was very deep, and in the end, even mutexes ended 
up expecting to have CAS.

So, in the end, I figured all you need is CAS, since everything is 
making the assumption that you have CAS. No point in trying to fight 
that one.

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

True. Except it's often

c &= ~x;

which is a BIC.

Also, if either a or b is a constant, the compiler can transform it at 
compile time to a BIC anyway, so it's only when you really need an AND 
that you get that extra complement needed. And I do find that that is 
rather uncommon.

But, as we both observed, it hardly hurts to add the AND as well.

  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