[libre-riscv-dev] Introduction and Questions

[Jeremy Singher]

> not micro-ops, *actual* scalar add ops.

I think we just have different terminology for this. To me, a micro-op
is the smallest unit of compute that is passed through a pipeline, and
a micro-op could indicate that the core should perform a scalar add
op. I'm happy with your explanation, though, thank you.

> it's basically c macros... applied to hardware.

Good analogy, thanks. The one concern I have is that this "vector op
fission" approach will pump the pipeline with tons and tons of
scalar-ops, while a traditional vector execution engine would not
deconstruct the vector instruction into many scalar instructions.

Does the vector pipeline use ALL the same execution resources as the
scalar pipeline? The same issue queues, functional units, read ports,
writeback paths?

> > How does the scoreboard handle a WAW hazard... two instructions
> > writing the same register? Does the second instruction wait for the
> > first to finish?

> sigh over a year ago i understood this enough to be able to answer.
> what we will have to do is simply ignore the optimisation opportunity.

Hmmm, ignoring WAW will significantly limit the ability of the core to
exploit ILP, which is one of the fundamental reasons for going OOO.

> no it does not.  you will need to state that you are happy to give
> credit if you use the book chapters, and that if you pass them on you
> will likewise ask the recipient to guarantee that they also will give
> credit to Mitch Alsup.

Of course, I'm glad to have the conditions of use AOT. Its incredibly
annoying when one is provided some information, only for the provider
of the info to come back months later and tell you "Remember that
document I sent you, yeah, make sure you never reference it in any
published work ever".

> Here are the chapters.

Thanks, Yehowshua.

Best,
Jeremy

On Fri, May 15, 2020 at 3:48 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On Fri, May 15, 2020 at 11:15 PM Jeremy Singher <thejsingher at gmail.com> wrote:
> >
> > > it's basically a Cray Vector Loop
> > > (VL) except that VL, when set, actually *PAUSES* the Program Counter,
> > > and issues MULTIPLE instructions - using the one at the PC as a
> > > "template" - but incrementing the operand register numbers
> > > sequentially on each iteration of the loop from 0 to VL-1.
> >
> > So if you decode a vadd instruction, with VL=4, and a 1-wide pipeline,
> > the design would stall instruction fetch, and issue 4 "scalar" add
> > micro-ops with incrementing register indices?
>
> not micro-ops, *actual* scalar add ops.
>
> > That seems like it
> > should work, although you would lose the ability to exploit vector
> > chaining, since pausing the PC would prevent additional instructions
> > after the vector instruction from getting issued.
>
> nope :)  because the Out-of-Order scoreboard takes care of them.
> they're *literally* simply as if you had had 4x (or 8x, or 12x, or
> 16x) scalar ADD multi-issue instructions shoved into the execution
> engine.
>
> any following 4x instructions (or however many) *will* still have the
> register numbers - different or otherwise - and thus *will* have the
> Read and Write Dependency Hazard tracking applied to them.
>
> it's basically c macros... applied to hardware.
>
> > I looked a SimpleV a
> > while ago, and to me it seemed like the difference vs a normal vector
> > architecture was that SimpleV merged the vector and integer register
> > files.
>
> no, it's waaay more than that.
>
> > > this has "implicit"
> > > register-renaming automatically built-in to the design.  these are the
> > > Function Unit operand latches.  they are best termed "nameless
> > > registers" rather than "register-renaming".
> >
> > I think I understand what you are saying, my terminology for this is
> > that the core is "renaming" registers into what you call inflight
> > "nameless registers". At the end of the day, the point is that
> > register data is stored not just in a logical register file,
>
> correct... it is "in flight".  the distinction is important because a
> lot of people try
> to *explicitly* add register-renaming hardware, register caches, and *actually*
> rename the registers by providing a PRF-ARF (physical / architectural)
> register file naming scheme.
>
> we maaay have to do that (because we will have a 128 entry regfile and
> the Dependency Matrices need to be of the size of the actual regs in use).
>
> however it will be to *DOWNSIZE* the register numbers... *NOT* "upsize"
> them as is normally done with e.g. x86.
>
> > and that
> > the scheduler can aggressively execute instructions OOO when their
> > operands are available, instead of in serializing execution in program
> > order.
>
> correct.
>
> > How does the scoreboard handle a WAW hazard... two instructions
> > writing the same register? Does the second instruction wait for the
> > first to finish?
>
> sigh over a year ago i understood this enough to be able to answer.
> what we will have to do is simply ignore the optimisation opportunity.
>
> > > Mitch Alsup had to write two
> > > additional chapters, as an addendum to James Thornton's book, "Design
> > > of a Computer", in order to correct Patterson's misinformation.
> >
> > Do you have a link to the addendum? I have a pdf of the book, but it
> > doesn't seem to have the addendum.
>
> no it does not.  you will need to state that you are happy to give
> credit if you use the book chapters, and that if you pass them on you
> will likewise ask the recipient to guarantee that they also will give
> credit to Mitch Alsup.
>
> these are the conditions under which i received the book chapters from
> Mitch Alsup, and, as the Copyright holder, he is entitled to request
> any conditions that he sees fit.
>
> if that's ok with you then i can send the chapters on to you.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev