Port-vax archive

[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:
Hi Johnny,

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

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

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

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, therefore they
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 worse)
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 common.

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 pipeline stalls...
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 instructions. There are examples on how to deal with it in even quite old books, like Patterson & Hennessy's architecture design book from around 1990.

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.

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

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

Home | Main Index | Thread Index | Old Index