[Libre-soc-dev] daily kan-ban update 24nov2020

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Nov 25, 2020 at 7:55 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> today:
> Finished the 16-bit compressed instructions demo:
> https://libre-soc.org/openpower/sv/16_bit_compressed/demo/
> I ended up writing an assembler in bash for the demo:
> https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/16_bit_compressed/demo_assembler.sh;hb=HEAD
> I also wrote an example predecoder that works with O(log N) gate depth
> that handles the full details of the proposed 16/32/48/64-bit
> encoding.

ah excellent.  nicely done.  i notice the key is to use something akin
to carry look-ahead.  this makes a lot of sense given that the modes
are mutually-exclusive.  neat.

https://en.wikipedia.org/wiki/Carry-lookahead_adder
btw fascinatingly carry look-ahead was the basis of one of the Aspex
ASP inter-processor instructions, allowing them to do literally
unlimited-length arbitrary-precision arithmetic.

> It outputs an array corresponding to 16-bit instruction
> memory units with a flag for each 16-bit unit indicating if that
> particular unit is the start of an instruction as well as the mode
> that instruction should be decoded in. I'm assuming it's relatively
> easy to figure it out from there.

should be yes.  a sinple naive version would perform an add-cascade (2
bits for operand 1, steadily increasing result accumulator) to produce
the indices needed to extract instructions from the correct location.
following that, in combination with the length/mode-detection those
indices can be used to extract the instructions for further (parallel,
independent) decoding.

that's going to be an arbitrary-shift-in shift register with an
absolutely massively-high number of read ports, and it'll definitely
result in a 2-stage decode.  first stage length second stage what's
currently PowerDecoder2 (and others).

> instruction decode modes are assumed
> to be kinda part of the PC instead of like VLE where they are set in
> the page table.

we're still going to need to mark pages as "variable-length" (with a
single bit) in order to distinguish them from pages that purely
contain ppc64le because 16/48 is, as you showed yesterday(?)
incompatibly-mixable with pure ppc64le word-aligned instructions.

l.