[Libre-soc-dev] NLnet Ongoing Grant

[Jacob Lifshay]

On Sat, Sep 2, 2023, 17:28 Luke Kenneth Casson Leighton via Libre-soc-dev <
libre-soc-dev at lists.libre-soc.org> wrote:

> i cannot entirely reveal why due to commercial confidentiality,
> but after some thought and Jacob's meticulous detailed estimates
> i think we need to pull the FP Unit entirely from the
> Ongoing Grant bug #961, park it for "Future" (given that for
> proper justice Jacob's estimates come out at EUR 24,000
> and that's not even including TestIssuer integration)
> and replace it with the following chain-dependent list of
> tasks:
>
> * removing use of PO1 and replacing with PO9
>

before we do that, if PO9 will ever have any 32-bit insns (icr if luke's
latest reversion of PO9 encodings is only 64-bit -- been a while since I
looked), I think we need to make space in bit 30-31 of the prefix for
things like Rc, otherwise we *can't* use the standard Rc-bit's location.
iirc luke had decided to put it off until he figured out the encoding,
since those bits can easily be swapped with other bits in the tables
defining the encoding. however, they are much harder to swap after we have
a bunch of sw using the encoding, so swapping should come first. Those
edits should only take me a small amount of time, if luke lets me do them.

* creating EXT200-263 under PO9
> * moving all LD/ST-post-update to EXT200-263, with their exact
>  respective *pre-update* EXT000-063 encodings
>  (example: lhz is EXT040, therefore lhzp *is* EXT240, no
>   arguing, no question: it just *is*)
>

I don't disagree here, but this needs a better rationale than "because I
said so", may I suggest "because symmetry and reducing decoder complexity"

* freeing up the LDST_IMM SVP64 "post-update" bit and allocating
>  it instead to Vector-Immediate (with elwidths on VIs)
> * using the reserved Normal/Arithmetic mode also for VI
> * finishing LDST-EXTRA-322
>
> this is a lot of work, definitely equal to the current EUR 8,000
> available budget, especially given that it involves:
>
> * specification writing and checking
> * insndb updating (two ways: PO9 itself *and* the new EXT2xx
> * a new PowerDecoder (for EXT2xx)
> * test_caller* unit tests
> * writing the LD/ST-post-update mdwn files (Nicholas, new member)
> * ISACaller updates
> * binutils updates (to SVP64 as well as a new EXT2xx area)
>
> there is also the strong possibility of Dmitry managing to make
> a Visitor-version nmigen Decoder, 100% compatible with the
> existing PowerDecoder (still using PowerOp Dmitry, that's
> very important) which is a task under cavatools (approved MoU),
> which would make creating EXT2xx a LOT easier, but we shall
> see how it goes.
>

Everything sounds good, though I am a bit disappointed that I couldn't
start working on implementing all the nice FP instructions for a change of
scenery.

Also, this means that #1026 can't have any FP ops, which means we will have
a much shorter list to choose from.

Jacob

>