[libre-riscv-dev] Introduction and Questions

[Luke Kenneth Casson Leighton]

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.