[Libre-soc-dev] v3.1B prefix
oliva at gnu.org
Sun Dec 13 21:52:11 GMT 2020
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
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
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.
| 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
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.
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
More information about the Libre-soc-dev