[Libre-soc-dev] v3.1B prefix

[Alexandre Oliva]

On Dec  8, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> On 12/8/20, Alexandre Oliva <oliva at gnu.org> wrote:
>> On Dec  7, 2020, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>> 
>>> i did find it odd that there's no 16-bit imm instructions,
>> 
>> Sorry, I failed to mention that they're not implemented yet.

> lol that would do it.  addi is the higher end of the opcodes used.
> although not being able to use it unless already in 16bit mode, this
> is very inconvenient.

I'm trying to implement the remaining opcodes now, but getting all
confused by the mismatches between the bit widths and range of values
supposed to be encoded:

| 0 | 1  | 2 | 3 4 | | 567.8 | 9ab  | cde | f |
| 1 | 1  | 1 | i2  | | 001.0 | RA!=0| imm | 1 | addis
| 1 | i2           | | 010.0 | RA!=0| imm | 1 | addi

* addi is EXTS(i2||imm) to give a 4-bit range -8 to +7
* addis is EXTS(i2||imm||000) to give a 11-bit range -1024 to +1023 in increments of 8

I suppose the bullets are lagging behind encoding updates, because:

- I count 5 bits for addis; if signed, that's enough for -16..15

- I count 7 bits for addi.  With a left-shift by 3, that makes for a
10-bit range.

If these were to be used the way I would conceive of them, the ranges
would be complementary, so that a pair of these insns could encode 12
bits.


Here's another issue:

| 1 | 0  | i2      | | 010.1 | RA   | imm | 1 | cmpdi

* all others are EXTS(i2||imm) to give a 7-bit range -128 to +127 (further for LD/ST due to word/dword-alignment)

- I count 6 bits, -32..+31.  It would take 8-bits to encode -128..+127.


One more:

| 1 | 0  | i2      | | 011.0 | RT   | imm | 1 | ldspi
| 1 | 1  | i2      | | 011.0 | RT   | imm | 1 | lwspi
| 1 | 0  | i2      | | 011.1 | RT   | imm | 1 | stwspi
| 1 | 1  | i2      | | 011.1 | RT   | imm | 1 | stdspi

* LD/ST r1 (SP) variants should be offset by -256

- With 6-bits immediate left-shifted by 3 (for d) we get -256..+248.
Offsetting by -256, we'd access only the red zone and another 256 bytes
range below the red zone, which is not at all meaningful.

- With 6-bits immediate left-shifted by 2 (for w) we get -128..+124.
Offsetting by -256, we'd access half of the red zone, and another 128
bytes below it.

- Bytes below the red zone are not even defined.  I suppose the intend
might be for sp loads and stores to have an unsigned offset, but even
then, for word-sized ones, the -256 offset would limit its use to the
red zone.


I guess at this point none of this really matters, but you were so
interested in the compressor estimates for 16-imm that I figured I'd
implement them, but...  tough.

What now?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist         GNU Toolchain Engineer
        Vim, Vi, Voltei pro Emacs -- GNUlius Caesar