We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
In the ARMv7-A/R ARM Issue C I found two instructions with odd encoding: PUSH and POP, encoding A2.
What's the Rt's role? I guess Rt and 'registers'-bitlist needs to match?
Encoding A2 ARMv4*, ARMv5T*, ARMv6*, ARMv7
PUSH<c> <registers> <registers> contains one register, <Rt>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 1 0 0 1 0 1 1 0 1 Rt 0 0 0 0 0 0 0 0 0 1 0 0
POP<c> <registers> <registers> contains one register, <Rt>
cond 0 1 0 0 1 0 0 1 1 1 0 1 Rt 0 0 0 0 0 0 0 0 0 1 0 0
It is using the pre or post indexed form of LDR and STR to push a single register rather than a register list so a completely different encoding. The 100 at the end is 4 rather than a bit in a register list. I suppose one could use LDRD STRD for two registers as well but they are much more recent instructions.
OK, thanks. It's just weird that there is one instruction for 2 - 16 registers and another for one register.
One would think that more general instruction would be easier to implement and use.
Also thanks for mentioning that the "register list" is not a register list but a constant.
The load/store multiple instructions are pretty complex. What's the point making them any good for a single register when they can use the simpler load or store register instructions and maybe save a little energy at the same time?
Actually more "general" instructions are harder to use, harder to decode and harder to execute! So it is often better to have a number of small, specific instructions rather than one generic one. The effects of LDM/STM on the complexity of the pipeline, for instance, are huge. As pipelines get longer and you start introducing speculative execution and register renaming, for instance, the necessary pipeline logic to unwind unwanted instructions and keep track of the registers.
As far as the present example goes, note also that the addressing modes are completely different for LDM/STM and LDR/STR so if you used LDM/STM as general purpose instructions and deleted LDR/STR, you would lose all the lovely flexible addressing modes of the latter pair.
Hope this helps.
Chris
I'd think implementing/using one instruction like LDM/STM is much easier than implementing/using 16,777,215 separate single instructions (that the one "replaces". :-)
The 4 uppermost bits are condition code and the next 3 bits tell it's LDM/STM, so the LDM/STM uses the rest (0 - 24) for its operands/modifiers for which the one and the same logic applies.
The assembly level equivalent is "symmetrical instruction set".
"so if you used LDM/STM as general purpose instructions and deleted LDR/STR, you would lose all the lovely flexible addressing modes of the latter pair."
No I didn't delete them, but I only have a couple of "group 1" LDRs and STRs: The basic one and the unprivileged one both register and immediate.
Then there is the exclusive one ("group 2") and special one ("group 3": double, signed, half word).
Those are instructions of their own right, not special cases of the same. The instruction word bits "mean" different things.
The coding for the basic LDT/STR immediate is:
where c c c c is the condition code, 010 is the "opcode",
P=post-increment
U=unsigned immediate
B=byte access
W=writeback
L=load/store
n n n n=Rn
t t t t =Rt
The 'x's are the immediate.
Much simpler than if there was a different instruction for each PUBWL-combination (32 immediate mode instructions instead of one, and another 32 register mode instructions).
In other "groups the "opcode" is different and (excluding gasic/register) the 'B'-bit has different meaning.
In other instruction it seems to select between double/half word or between register/immediate.
I haven't checked the LDM/STM-group yet.
Don't forget that the ARM instruction set as it exists today wasn't designed all in one go - has "evolved" over a long period of time. Different instructions and features have been added at different times and that explains why the original orthogonal, symmetric instruction set doesn't really appear that way any more!
By looking at the encodings: the instruction set keeps evolving in the future too.
There are big areas of possible instructions not yet in use.
That's the politics? To squeeze the instructions into smallest possible space so that even bigger new instruction groups can be added in the future.