RISC-V: Why set least significant bit to zero in JALR
Asked Answered
B

3

5

Why do we need to set the least significant bit to zero in JALR in RISC-V Instruction set as described in the RISC-V Instruction manual?

Is it for alignment propose?

enter image description here

Brushwood answered 6/11, 2016 at 19:42 Comment(0)
P
7

In RISC-V all instructions must be aligned to 4 bytes, but through extensions that allow 16, 48 or 64 bit instructions size, instructions are allowed to be aligned to 2 bytes. As described in the specification (V 2.1, p. 5):

The base RISC-V ISA has fixed-length 32-bit instructions that must be naturally aligned on 32-bit boundaries. However, the standard RISC-V encoding scheme is designed to support ISA extensions with variable-length instructions, where each instruction can be any number of 16-bit instruction parcels in length and parcels are naturally aligned on 16-bit boundaries.

So the least significant bit in the target address of JALR must always be zero. The developers of RISC-V wanted to reuse an existing format instead of making a new one, where the immediate is multiplied by two. As explained on p. 16 in the specification:

Note that the JALR instruction does not treat the 12-bit immediate as multiples of 2 bytes, unlike the conditional branch instructions. This avoids one more immediate format in hardware.

This isn't a real disadvantage, as implementations can you use the least significant bit of the pointers. One example would be to distinguish between function pointers and data pointers, which can be handy for interpreters. Also mentioned in the specification at p. 16:

[...] allows the low bit of function pointers to be used to store auxiliary information.

Putsch answered 7/11, 2016 at 20:5 Comment(2)
But why to proposefully set the last bit to zero instead of rasing an exception?Brushwood
The designers decided that it would be better to ignore this possible error case and that the software can use the bit for something. So if the function pointer contains an invalid address, then this error case will most likely raise another exception, like page fault, illegal instructions, misaligned address (note: 4 byte alignment) and so on. Without proof I would guess that it is more likely that an erroneous address will generate a page fault or illegal instruction exception than to be an odd address.Putsch
R
6

The smallest instruction in RISC-V is 2 bytes. No valid RISC-V instruction starts at an odd instruction, so there would be no purpose in allowing the least significant bit to be 1.

Royceroyd answered 7/11, 2016 at 0:42 Comment(3)
But why doesn't it fault if you use a bogus address, instead of silently going to the nearest valid address? Is this useful for covering multiple cases in jump tables or something?Stoa
I agree with you Peter Cordes, shouldn't this raise an exception instead?Brushwood
@akurd: fsasm's answer already covered that: to allow tagging pointers by using the low bit to store a boolean. That explains this intentional design decision.Stoa
N
2

I don’t know the RISC-V architecture, but my guess is the following:
Immediate addressing allows you generally to access any memory address, e.g. a single byte at an odd memory address (least significant address bit = 1).
A jump, however, is always done to an even address, so that the next instruction can be fetched in a single cycle (and not in two cycles, as it would be the case when the jump address - and following instructions - had a least significant address bit = 1).
Thus the RISC-V architecture apparently enforces to fetch instructions only from even addresses.

Numismatics answered 6/11, 2016 at 20:59 Comment(1)
In RISC-V all instructions must be at multiples of 4 and all instructions are 4 byte long. If the Compressed ISA extension is supported (it currently isn't marked as final) instructions are allowed to be multiples of 2. Also if future extensions specify instructions that are larger than 32 bit, like 48 bit and 64 bit, they are also allowed to be at multiples of 2.Putsch

© 2022 - 2024 — McMap. All rights reserved.