[Libre-soc-dev] unauthorized SVP64 specification changes

[Luke Kenneth Casson Leighton]

On Sunday, September 17, 2023, Jacob Lifshay <programmerjake at gmail.com>
wrote:

> sorry, I was too tired to think clearly enough to push the changes to a
separate branch. I will try not to repeat that error.

i do appreciate that the bigmul work is dependent on it,
so you went ahead in the master branch. this brings additional
complications (for you) as well as risks destabilising
the absolutely absolute critical hard-rule that the spec *is*
at all times implemented 100% in ISACaller without any
exception of any kind.

inconvenient as it is
we need a branch/review/approve process because if you are
going to propose changes to the spec i need *and have always*
needed time *offline* of potentially *several days* to think
about them, recall (out of long-term chemical memory-storage)
any impacted locations, and advise where they can be found.

this spec is *250* pages and extremely complex, you have no idea
how complex it really is, and even i cannot keep all of it
in short-term memory-recall.

you missed for example that although you updated the pseudocode
for CR EXTRA2/3 you did not do the corresponding GPR/FPR code
in the same commit. i don't know exactly where it is, i just
know it's there *and don't have time to find it*, that's down
to you.

reminder: when making changes to the spec it is of ABSOLUTE TOP
PRIORITY ABOVE ALL ELSE WITHOUT FAIL that they be correctly
implemented IMMEDIATELY at the same time in ISACaller with
NO OTHER DEPENDENT WORK BEING CARRIED OUT UNTIL ISACaller IS
UPDATED, and unit tests created.

(you already made the mistake of rushing ahead with the bigmul
REMAP being hard-dependent on an Unauthorized modification of
the specification, so you now know *why* there is the above
hard rule).

that said the fact that you picked up the error is extremely
important: the solution however may turn out to be more
complex and more involved than the PRELIMINARY (Unauthorized)
fix that you implemented, in order to save gates at the Decoder.

given that that involves huge modifications right down the chain
of dependencies right the way through spec HDL ISACaller binutils
it has to be properly evaluated for its time and cost to the
project.

the good news is that you wrote unit tests for picking up
the (interim, unapproved) fix. i have a suggestion there which
i will put on the bugreport, for ISACaller / TestIssuer.

https://bugs.libre-soc.org/show_bug.cgi?id=1161#c6

there is no higher priority task for you at the moment, jacob,
and no other task until the interim fix is in (see comment 5).
i.e. follow the hard-rule "under no crcumstances do anything
else: treat this spec-change task with associated ISACaller
changes as an Atomic Operation"

i have raised it to the absolute maximum level permitted by
bugzilla. we'll sort out a budget later (somewhere under OPF ISA)

yes i am aware that TestIssuer and ISACaller have limits on
the range of CR Fields (max 8 when it should be 128), do take
that into consideration when writing the tests (@"skip").

l.



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