When providing negative immediate offset (step) values to the JUMPR and
JUMPS opcodes, the resulting instruction contained an incorrect offset.
This commit fixes that behaviour.
This is the same issue that affected the ESP32 code. See previous commit for
more technical detail on the issue.
When providing negative immediate offset (step) values to the JUMPR and
JUMPS opcodes, the resulting instruction contained an incorrect offset.
This commit fixes that behaviour.
According to the technical reference manual (TRM)
[https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf]
the magnitude of the relative shift from the current position is determined
by bit 0-6 of the step field, and the direction is determined by bit 7,
with 0 meaning PC+step, and 1 meaning PC-step.
(For comparion, the ULP C macros in the ESP-IDF implement this as described
in the TRM. All step values passed to the relevant JUMP macros will result in the
instruction step field having bit 7 indicating the sign and bit 0-6 holding the
absolute value of the offset.)
This fix modifies the I_JUMP_REL{R,S} macros to set the step field correctly
for negative immediate values. Since symbols, which are resolved later during
the BFD relocation phase always evaluate to 0 at this stage (from EXPR_VALUE),
this change to the macro only affects the case of immediate values (as can be
seen from all previous test cases resulting in the same listing output as
before). The relocation code (in function esp32ulp_jumprelr_reloc) already did
this correctly for symbols, and thus remains unchanged.
Example of the issue:
For an offset of -2, the step field should have looked as follows:
bit 0-6 = 2 # positive 2
bit 7 = 1 # 1 means negative
However, the result was actually:
bit 0-6 = 126 # negative 2 (two's compliment)
bit 7 = 1 # 1 means negative
