Port-vax archive

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

Re: New Vax - future directions :-)

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

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

Home | Main Index | Thread Index | Old Index