Live data from Hacker News

ARM immediate value encoding

alisdair.mcdiarmid.org

51–60 of 71 posts

Re: ARM immediate value encoding

#51
post #49

Earlier quoted context omitted.

This was part of the beauty of ARM when I learned it as a teenager back in the early 90s. Very simple and elegant, and writing ARM code by hand was enjoyable. Coming back to ARM now, though, in this form of Cortex-M microcontrollers, I see that things have become muddied with things like if-then-else instructions and mixed 16-bit/32-bit Thumb-2 code.

Simple, elegant, and it eats an astonishing 12.5% of instruction bandwidth (4 bits out of 32). A branch will require less space as soon as you want to conditionally execute over 8 instructions. On top of that, for that is executed unconditionally (in practice, maybe not most of the instructions if you look at the binary, but almost certainly most of the instructions if you count ones executed multiple times) So, a ne…

arm64 ... sort of ditches conditional execution. It’s not on every instruction any more, but it’s still available on more instructions than on most other arches.

To the usual complement of typical conditional instructions (branch, add/sub with carry, select and set), arm64 adds select with increment, negate, or inversion, the ability to conditionally set to -1 as well as +1, and the ability to conditionally compare and merge the flags in a fairly flexible manner (it’s really a conditional select of condition flags between the result of a comparison and an immediate). This actually preserves most of the power of conditional execution (except for really exotic hand-coded usages), while taking up much less encoding space.

Re: ARM immediate value encoding

#52
Why is this cool and clever? It still only encodes 12 bits of data, it is just different to using the normal 12 bits of data.

Is this a more useful subset? I am guessing it is so, since they went to this trouble.

Re: ARM immediate value encoding

#53

Earlier quoted context omitted.

I remember there was a "never" condition, which was present just for completeness; it turns out ARM eventually found that having 2^28 different NOPs would not be a good use of opcode space, so it's now a special extension for newer instructions...

I seem to recall from my ARM Assembler coding days that there was also a noop instruction, which of course could be conditional itself, so if you didn't actually want to do the NOOP, you could do NOOP-NE, which wouldn't do anything twice over.

From my days coding ARM assembly on the Acorn Archimedes, NOP was typically an alias for MOV R0,R0 (which effectively did nothing) rather than being its own instruction.

Re: ARM immediate value encoding

#54

Article begins by praising RISC as "elegant" and "a good design decision", goes on to describe limitations of RISC immediate values.

You're being a little disingenuous. It describes the ARM architecture as 'elegant', and 1/4 of the way through the article describes the common use of fixed length instructions in various RISC architectures as 'a good design', and explains why this is mostly a win. And then it explains how the ARM manages to encode a wide range of useful immediate values using a very elegant and simple scheme.

In all my years coding in ARM assembly language, the range of immediate values it supported was rarely if ever an issue.

Re: ARM immediate value encoding

#55
post #52

Why is this cool and clever? It still only encodes 12 bits of data, it is just different to using the normal 12 bits of data. Is this a more useful subset? I am guessing it is so, since they went to this trouble.

It can generate 4096 different slightly useful 32-bit values. For others, you may assemble them using a variety of methods.

Re: ARM immediate value encoding

#56
post #55
post #52

Why is this cool and clever? It still only encodes 12 bits of data, it is just different to using the normal 12 bits of data. Is this a more useful subset? I am guessing it is so, since they went to this trouble.

It can generate 4096 different slightly useful 32-bit values. For others, you may assemble them using a variety of methods.

It generates fewer than 4096 unique values, as some values map to the same thing. The most obvious being that 0 shifted any number of places produces 0, but also 0x10 shifted left 0 is the same as 0x04 shifted left 2 is the same as 0x01 shifted left 4.

Re: ARM immediate value encoding

#57
This encoding is nice given that they've already paid the price of having the 32b barrel shifter, but it was a non-obvious choice to have the barrel shifter to begin with. Most instructions don't benefit from the optional rotate, but they pay the price in the encoding and in the data path.

Interestingly, the website uses svg for illustrations, IE 8 and under be damned.

Re: ARM immediate value encoding

#58
post #33

Earlier quoted context omitted.

> I was expecting it to be a lookup table. There's one ISA I've worked with before that does have -2, -1, 0, 1, 2, and some other "commonly used constants" like powers of 2 encoded specially in the immediate. I think it was an 8-bit, but I can't remember exactly which one. Anyone know what I'm referring to?

MSP430?

If the reply link is missing on a comment (it does that after the comments get to a certain depth of nesting) then click on the comment's "link" and you'll get a text box you can reply into.

Re: ARM immediate value encoding

#59

Earlier quoted context omitted.

I seem to recall from my ARM Assembler coding days that there was also a noop instruction, which of course could be conditional itself, so if you didn't actually want to do the NOOP, you could do NOOP-NE, which wouldn't do anything twice over.

From my days coding ARM assembly on the Acorn Archimedes, NOP was typically an alias for MOV R0,R0 (which effectively did nothing) rather than being its own instruction.

And if you ever needed to manually patch in an easy-to-remember NOP, 0x00000000 was ANDEQ R0, R0, R0.

Re: ARM immediate value encoding

#60
post #55

Earlier quoted context omitted.

It can generate 4096 different slightly useful 32-bit values. For others, you may assemble them using a variety of methods.

It generates fewer than 4096 unique values, as some values map to the same thing. The most obvious being that 0 shifted any number of places produces 0, but also 0x10 shifted left 0 is the same as 0x04 shifted left 2 is the same as 0x01 shifted left 4.

Makes sense. Well... It produces less than 4096 interesting 32-bit values.
Post reply on HN