[Libre-soc-dev] bitmanip planning
luke.leighton at gmail.com
Fri Nov 5 07:06:03 GMT 2021
On November 5, 2021 3:45:46 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Thu, Nov 4, 2021 at 3:59 PM lkcl <luke.leighton at gmail.com> wrote:
>> >, though the
>> >encoding might be more trouble.
>> yes. it barely fits.
>Assuming we want to use major opcode 22 for bitmanip instructions for
i made an effort to fit the two but prioritised SV.
we are never going to be able to fit entirely into 22, not going to be able to fit into 2 major opcodes either.
it would be better to pick another major opcode, which is perfectly fine given that this is a test ASIC.
if there was an intention to go to production, OPF would reasonably have grounds to jump up and down and raze the project to the ground.
all of the VSX opcodes are available as far as we're concerned, and there are a couple of other nonallocated ones.
> we'll need to decide what to do with the SV ops that are taking
>up that space, currently we have:
>I propose we reassign them to fit in the mode field of ternary:
>0b10001 svshape/svremap/svstep determined by using bits 21..25
svshape, remap and svstep were a frickin massive amount of work and modifying them now would be extremely disruptive.
>This leaves space for the other encodings:
>Should I just do that in the csvs or are there other places that need
>to be simultaneously updated?
trans/svp64.py encoder, and a few other places, it's extremely complex and a lot of moving interrelated parts.
if you look at the sheer size of svshape and svremap it should give you some idea of how much is involved.
one "simple" looking change could take a week (7% of available time) to go through everything and make sure all the unit tests still work.
better to just drop the entirety of bitmanip into another major op and not worry about it.
production can use an opcode namespace, worry about that later too.
More information about the Libre-soc-dev