[libre-riscv-dev] daily kan-ban update 14may2020
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu May 14 19:55:41 BST 2020
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
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
off the list.
this makes for a much simpler target and increases the chance of success for
our first test chip.
More information about the libre-riscv-dev