[Libre-soc-dev] bitmanip planning

[lkcl]

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
>> >instruction
>> >encoding might be more trouble.
>>
>> yes. it barely fits.
>
>Assuming we want to use major opcode 22 for bitmanip instructions for
>now, 

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:
>bits 26..30:
>0b00000 setvl
>0b00001 svshape
>0b00010 svremap
>0b00011 svstep
>
>I propose we reassign them to fit in the mode field of ternary:
>bits 26..30:
>0b00001 ternary
>0b01001 setvl
>0b10001 svshape/svremap/svstep determined by using bits 21..25
>0b11001 TBD

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:
>bits 26..30:
>0b00000 ternaryi
>0b00001 ternary
>0b00010 bitmask
>0b00011 xperm/reserved
>
>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.

l.