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!
Thanks!
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.(http://www.bitsavers.org/pdf/dec/dtj/dtj_v01-01_aug1985.pdf)
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 :-)
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.On 2021-07-03 15:13, Anders Magnusson wrote:Hi, 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 theycan 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 becareful 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...
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 wbackso, OA is calculated from ab and the result is written back to PC (which is a fake arg).
-- R