[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New vax - implementation :-)
On 2021-07-05 19:23, Anders Magnusson wrote:
Den 2021-07-05 kl. 18:40, skrev Johnny Billquist:
Sorry for jumping in so late in this thread. I've been out a couple of
But first of all, this is very cool, Ragge. Nice!
Did you ever read the first issue of the DEC Technical Journal? It's
all about the VAX-8600, in quite some detail, including the pipeline
If you haven't read it, maybe you should. It might be inspirational,
and maybe also give an idea or two to pick up.
Very interesting! No, I hadn't read it, but now I have.
Funny, DEC used the same pipeline steps as I do, but I seem to have gone
a little bit further in the arg evaluation steps :-)
I suspected there might be some similarities in the approach from your
This problem isn't specific to the VAX, you have the same problem on all
CPUs where you are allowed to use the same registers in consecutive
There are examples on how to deal with it in even quite old books, like
Patterson & Hennessy's architecture design book from around 1990.
On 2021-07-03 15:13, Anders Magnusson wrote:
Den 2021-07-03 kl. 14:50, skrev Rhialto:
On Sat 03 Jul 2021 at 13:14:46 +0200, Anders Magnusson wrote:
All of these steps are (mostly) independent of each other,
can easily be pipelined.
Until you get to instructions with modify a register in one operand and
use it again in another :) such as (ok I took those examples from the
PDP-11 architecture handbook in the section where it describes how
different models do different things; but for a VAX you'd have to be
careful too and with 6 operands the number of combinations is much
Thought of this already :-)
The register value is modified in the ADDTO state, and at the same
time saved in a "restore" register in case a page fault or something
happens later on that requires rollback. The restore register
follows in the argument pipeline.
If two (or more) arguments uses the same register there are two ways
of dealing with it (I haven't decided which to use yet):
- Stall the pipeline one step to catch up with the new reg value
- Have a check whether the result from the parallell pipeline uses
the same reg and directly fetch the result.
I am leaning on the first way of doing it, since it will be quite
uncommon, and one pipe step is cheap.
E.g. instructions like ADDL3 (r0)+,(r0)+,(r0)+ are not especially
I think if you are going with pipelining, the more interesting problem
happens when different instructions also depend on the results of each
other. This is where it becomes more complex, and in the 8600 there
appear to be both forward and backward dependencies that can cause
Oh. Certainly. It's nothing VAX specific about it. But it is a kind of
problem to consider. And it's not just about registers either. Memory is
the same story. And condition codes...
And then you have to define how it should behave if you modify your
instruction stream... Self modifying code... Yummm...
You'll probably find research papers going back to the IBM Stretch in
the 60s, where they first started to deal with this.
It's very well defined. All arguments are evaluated in order, before
the instruction itself.
So, in "jmp (r0)+", OA is calculated first, then r0 is increased, then
PC is set to OA.
ADD Rx,(Rx)+ ; Rx gets incremented or not before being
ADD Rx,@-(Rx) ; used as a source operand
MOV PC,offset(Rx) ; value of PC either before or after fetching
; offset from the instruction stream
JMP (Rx)+ ; Rx gets incremented or not before being
; copied to PC
and JMP is weird because it's more like a LEA arg,PC, if there were a
Load Effective Address instruction.
These examples are interesting and ambiguous on the PDP-11. On the
VAX, I believe that the behavior is well defined. So it's just a
question of implementing them the way they are defined to behave.
My instruction definition looks like this:
JMP ab,wl#pc lbl=mov wback
so, OA is calculated from ab and the result is written back to PC (which
is a fake arg).
Right. So nothing really tricky to see here on the VAX.
Now, if this was a PDP-11, then the answer would be "undefined". :-)
Some do it one way, others not...
There are reasons for all the detailed specifications of the VAX. They
didn't want to repeat the mistakes from the PDP-11...
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 |