Adding section describing the software view of the load/store instrs

[christian-herber-nxp]

No description provided.

[tariqkurd-repo]

I think this is fine, and it avoids the problem of overwriting the address operand if it is also one of the destination registers.

[ubc-guy]

with the currently written up description, ld and sd instructions may appear as a load or store of byte operations in any order and may be repeated; further, the load performs a single atomic update to the register pair.

I have a few concerns with the way this is written:

a) atomic updates to the register pair require additional resources, particularly a dword size buffer which first accepts the byte and then commits; to avoid increasing latency by 1 cycle, the entire dword would also have to be bypassed with muxes. in other words, providing this simple software view requires an expensive hardware solution.

b) this atomic update text seems to contradict an earlier note within the current spec:

NOTE: Therefore, implementations are not required to ensure atomicity in loading/storing to/from the individual registers relating to a 64-bit operand.

c) the cm.pop instruction does not require atomic updates of their multi-register destinations

d) do lh/lw/sh/sw instructions behave similarly, ie breaking down into bytes? if so, there are no further concerns here. however, the only similar description I could find regarding a breakdown into bytes is cm.pop and cm.push so we'll continue on to (e) below.

e) from the Unpriv Manual, naturally aligned operations (eg halfword aligned for halfword operations) behave atomically but unaligned ones do not. the precise text from Unpriv is below:

Furthermore, whereas naturally aligned loads and stores are guaranteed to execute atomically, misaligned loads and
stores might not, and hence require additional synchronization to ensure atomicity.

NOTE: We do not mandate atomicity for misaligned accesses so execution environment
implementations can use an invisible machine trap and a software handler to handle
some or all misaligned accesses. If hardware misaligned support is provided, software can
exploit this by simply using regular load and store instructions. Hardware can then
automatically optimize accesses depending on whether runtime addresses are aligned.

f) the UnPriv Manual seems to contradict itself between lh/sw/sh/sw and cm.push/cm.pop, which is not good.

g) i think the correct response is a compromise, where individual words (not bytes) are updated atomically by cm.push/cm.pop; the solution here, for ld/sd in rv32, would then to also have individual words be updated atomically (but not the pair).