Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New Vax - future directions :-)

On 2021-07-05 21:39, Anders Magnusson wrote:
Den 2021-07-05 kl. 20:29, skrev Johnny Billquist:

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

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


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.


is obvious. It clears all the bytes at address 0 to 7.


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.

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

Home | Main Index | Thread Index | Old Index