[libre-riscv-dev] building a simple barrel processor

[Luke Kenneth Casson Leighton]

jacob, thanks for this: there are a lot of things that i don't follow
(at all, such as why a branch can be resolved earlier just because of
strict 1/N time-scheduling), which are going to need a detailed
investigation.  i could understand if they were features being
proposed that had nothing to do with 1/N round-robin time-slicing.

before getting into that, i just need to check to make absolutely sure
that you're aware that a barrel processor is a *strict* - hard-wired -
round-robin time-sclicing design.

as in: if there are 4 time-slices and the core runs at 800mhz, that's
effectively 4x 200mhz time-sliced threads, and there's *absolutely no
way* that one of those threads can run at anything *other* than
200mhz... EVER.

as in: if you have 4 hard-time-sliced threads, and 3 of them need to
block or context-switch, the one remaining hardware thread will run...
*AT 200 MHZ*.

a software context-switch on any one of those 4 threads will run...
*at 200 mhz*.  all 256 registers on any one of those 4
hard-time-sliced threads will be context-switched... *at 200mhz*.

that means that when we go to investors or to the wider public, and
say that we are doing an 800mhz 4-core 4-time-sliced barrel processor,
we're actually saying that there are 16 hardware threads where if
there is ever a need for single-threaded execution, the *MAXIMUM*
performance is... *only 200 MHZ*.

i do not believe that such a proposal, for general-purpose usage in
the year 2019, would ever be taken seriously.  as in: i can't possibly
go back to the client / sponsor and say that we're going to do a
processor design that's only capable of 200mhz single-threaded
execution.

he'd tell me that he'll go use a 4-SMP rocket-chip, which has been
silicon-proven to do 1.5ghz a number of times, and he'll license
Vivante's GC800 3D engine for USD $250,000.

so this is why i said that yes, a barrel processor (a strict 1/N
round-robin hard-time-scheduler of a Nx multiplied register file plus
state) would be a great boot-up management core and also as a
soft-peripheral (I/O) core, post-boot.

so can i just check that we're on the same page, here, about what a
barrel processor actually is?

from what you've written, you may be under the impression that if one
of the hard-wired hard-round-robin-scheduled barrel threads stalls
that the execution time-slot is permitted to be utilised by
*non-blocked* threads.  from what i understand of such a conceptual
design, that is *NOT* defined as a barrel processor, it is defined as
a "single-issue hyperthreaded design".

can you clarify?

l.