[Libre-soc-dev] svp64

[Luke Kenneth Casson Leighton]

status:

* tidied up some tables, shrank their width so they don't scroll when edited

* prepared for autogenerating tables, reg names and reg profiles

* realised (finally) that the reg names were not those that were designed
and discussed in detail 18 months ago.

* realised that there is a real quick and dirty way to get binutils
useable, a 32 bit svp64 0xNNNNNN instruction.

* also realised that data-dependent fail-on-first is going to screw us.  it
is the only operation that *requires* VL to be allowed to be set to zero.
 data-dependent LDST throws an exception but doea not set VL=0.

* still do not know what the best arrangement for CRs is.

some thoughts here.

firstly: the names and the encoding.  the original SV-P48 and when extended
to SV-P64 specifically allowed scalar non-vectorised reg numbering to be
directly mapped into the SV numbering, when the EXTRA field was 0b00 or
0b000.

the new naming was not proposed with an explanation in words that the
intention was to abandon this previous decision and analysis.  consequently
in combination with it not being at all obvious it took *four days* to
finally realise that it had changed.

the time crunch that we are under it is critical that we take as many of
the original concepts and transfer them as quickly as possible to the
rewrite.

for example i lifted the LD pseudocode from the original SV spec,
cut/pasted it into a new page and took 20 to 30 minutes or so to read,
review, alter, re-read, review again, think again, and go "yep done, next
task".

not, as it had been originally, take *two weeks* to research and reinvent a
new LD vectorised pseudocode.

i checked, "is this the same concept yes or no yes right good enough
declare done move to next task, bam bam bam bam next next next next".

this is what we need to be doing, not taking the opportunity to throw away
existing work and reinvent it.

along the way there will be fantastic opportunities to add things,
particularly because of the CRs.  these areas will be - are - hard enough
as it is without having to add to that task by abandoning good /
already-made decisions.

some of those things, the little tweaks, may not work out.  the
vertical-horizontal CR naming may be too complex to implement.  and the
fact that VL is not permitted to be set to zero (because there is not
enough room in the SPRs to store 7 bits 0-64, only 6 bits to represent
1-64), this is a huge pain.

the choices here are: abandon data-dependent ffirst or spend a huge amount
of time reviewing the SPR layout.  neither are good choices when we are
under time pressure.

l.







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