xc.ld.[h|b] about xcrypto HOT 3 CLOSED

@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.

from xcrypto.

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

from xcrypto.

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.

from xcrypto.