[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:
Both. The two Q instructions that exist would do the same on memory
but not on registers.
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?
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.
Yep, the distance, but not as a displacement. Having a struct larger
than 2G? Quite uncommon.
There are as I can tell only two things in the addressing modes that
- 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.
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
Biggest problem with them are that they are bitfield instructions, hence
tedious to evaluate.
Basically everyone needs something else than the queue interlock
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
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.
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
In a C compiler you only have AND, so when translated it usually ends
up with a COMPL as well.
- 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.
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
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
Main Index |
Thread Index |