Re: New vax - implementation :-)

[Johnny Billquist <bqt%update.uu.se@localhost>]

Hi.

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

I suspected there might be some similarities in the approach from your 
description. :-)

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

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