[libre-riscv-dev] daily kan-ban update 14may2020

[Luke Kenneth Casson Leighton]

On Thu, May 14, 2020 at 7:28 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
> (some types in Rust aren't allowed to have certain values so rustc exploits
> that fact to pack other information into those bytes to save space.

interesting!  and scary :)

> I'm planning on attending the OpenPower virtual coffee call later today,
> and will try to make some progress on the load/store execution pipeline.

cool.  my routine for a few days now:
bashing my head against the LD/ST FSM.... i do a little bit each morning,
scream loudly somewhere after lunch, and do a bit of ALU in the afternoon :)

> I may also work on a mul/div function unit, since Luke asked me to do that,

(btw i did popcount, if i can't stand the LD/ST FSM i'll try parity)

> though I think integer mul should be part of the fp mul pipeline since they
> can share multipliers, and integer div should be part of the
> fdiv/idiv/irem/udiv/urem/fsqrt/frsqrt ALU pipeline that I wrote a lot of
> previously.

yes.  so the DIV pipeline would need to be set up to take minimum 64-bit wide
ints, even though FP64 only takes... 53(?) for the mantissa.  likewise for MUL.

although a couple of things:

* i'd contemplated that there be some "hidden Function Units) and some
  rewriting of Function.OP_xxxx into "micro-ops"... this is complex so is
  off the "priority list"
* FP is also off the "critical priority" list for the 180nm test chip
* so is Partitioning

this drastically cuts down on complexity.

so although we can - and should - use the integer DIV ALU code that you wrote,
(and need to convert it to partitioning at some point) the partitioned
multiplier is
off the list.

this makes for a much simpler target and increases the chance of success for
our first test chip.

l.