xc.ld.[h|b]

[ben-marshall]

These instructions are versions of xc.ld.hu and xc.ld.bu which blank the rest of the register rather than updating a specific part of it.

The "u" in "hu" and "bu" stands for "update" rather than "unsigned", which might be worth pointing out explicitly in each of the instructions which use it.

• [x] Specification updates
• Encodings
• Binutils
• [x] Formal models
• ISE Models
• [x] RTL

[ben-marshall]

@danpage - The load and store instructions are really tight on the encoding space. We can't fit two extra instructions like this which have the same flexibility as their "u" counterparts.

The idea behind the "u" versions was to be able to load a word worth of bytes from different places without needing to do things like shifting and masking.

Given this intended use case, would it be sensible to make the versions of xc.ld.[h|b]u where the byte/halfword of the destination register is the zeroth one blank the rest of the register. This is a change of functionality to the existing instructions, rather than adding new encodings.

It would mean you can't load to the zeroth byte/halfword of a register without blanking the rest, but I don't see that being much of a constraint if you were going to load the rest of the register with data anyway.

[ben-marshall]

xc.ld.b x, y(z) would then be a pseudonym for xc.ld.bu 0,0,x, y(z)

[ben-marshall]

Decision:

• No new dedicated encoding.
• Existing xc.ld.[b|h]u where h or b are non-zero continue to behave as before, updating the addressed byte or halfword and leaving the others un-modified.
• Existing xc.ld.[b|h]u where h and b are both zero will write the loaded bytes to the least significant portion of the destination register. The other high bytes are then cleared.
• This means we can still load a complete word-worth of register with disparate memory values without having to do expensive shifts and masks, so long as we always load the least significant byte/halfword first.