[libre-riscv-dev] next tasks

[Michael Nolan]

Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes:

>
>>  or more like
>> the decoder on my custom cpu design which just pulls out the register
>> fields and selects whether it's an ALU or memory etc. instruction?
>
>
> kinda like that, too :)
>
> bear in mind, the data (registers) get dropped into "Function Units".  have
> a look at Mitch's book chapters.
>
> they do NOT go "directly" into pipelines.
>
> then take a look at the 6600 experiment code in the soc repo.
>
> i have already started creating "internal" opcodes for ADD SUB MUL and so
> on.

Is this in soc.git/src/experiment
(https://git.libre-riscv.org/?p=soc.git;a=tree;f=src/experiment;h=915526d5d3e4a717db2c015322849d14a167dcf7;hb=HEAD)? 
>
>
>
>> Since we're switching between POWER and RISCV at runtime and making an
>> OOO processor, I'm suspecting it's going to be more like the former
>
> bear in mind it is as if we have a 33 bit instruction.
>
> the top bit simply selects as a mux the different ISAs.

Right my point with that was that there would be a bit of translation
going on because the POWER or RISCV instruction set doesn't *exactly*
line up with our backend.

>
> microcoding we can do by setting "state bits" that ask partial results to
> be fed BACK from the output of one pipeline UP to the Function Units again,
> and feed it into a new pipeline.
>
> so say we could have a signed/unsigned extender pipeline that receives
> aaaallll partial data
>
> but
>
> there is no such actual opcode.
>
> however in the "intermediary" expanded internal opcodes we have a bit set
> which goes "if this is set then after result computation, shove me through
> the signed pipeline and clear the bit saying i been there".
>
> make any sense?

So this would be more like a bundle if you will of multiple operations
grouped together? So for instance the POWER instruction `lwzu r1, D(r2)`
might be decomposed into:

<add r2, r2, D | load.w r1, [r2/partial result]>

It seems to me that it might be more efficient area/power wise to split
it into two separate instructions, reducing the width of the instruction
path and removing the feedback mechanism, but increasing pressure on the
register file and OOO machinery. Apologies if this doesn't make sense
for the 6600 style of machine, it's difficult to wrap my head around still.

--Michael