Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ARM immediate value encoding

alisdair.mcdiarmid.org

Post reply on HN
Print view View original

61–70 of 71 posts

Re: ARM immediate value encoding

#61

Post by userbinator »

theatrus2 wrote: post #38
userbinator wrote: post #28

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?

The MSP430 has a constant generator register, which depending on the access mode used will generate offsets and zero. I'm sure there are a few others.

That's the scheme. Although probably MSP430 took its inspiration from the one I had in mind since I was thinking of an 8-bit MCU from the early 80s - might've been Motorola.

Re: ARM immediate value encoding

#62

Post by axman6 »

stephencanon wrote: post #26
wreegab wrote: post #22

I was left with one question after reading the article: the purpose of the condition field in the instruction.

In the ARM instruction encoding, every arithmetic and logical instruction is "conditional". The destination register is either updated or not depending on the four bit condition field and the state of the condition flags in the processor. As a simple contrived example, consider the following C code: int a[100], b[100], count; ... for (int i=0; i b[i]) count++; } without conditional execution, one might compile this t…

Your last sentense made me realise why ARM64 no longer has conditional instructions. Obviously it's designed for higher power situations than most ARM cores, and OOO is an important part of doing that efficiently. reduced instruction deps == better OOO.

Re: ARM immediate value encoding

#63

Post by joezydeco »

samatman wrote: post #41
joezydeco wrote: post #37

Earlier quoted context omitted.

That's a beautiful explanation. It's one of my favorite things about the ARM instruction set. That said, it also means debugging becomes a bit more painful. Let's say you want your (cheap) JTAG debugger to halt on the count++ instruction. You can hard break on that particular address in code, but you will always hit that address whether the condition was met or not.

Knowing nothing about the tools, why can't you set a breakpoint based on a bitmask of the instruction pointer? I'm new to the assembly world, I've been working my way down and have gotten as far as Forth.

Better tools can, thus the (cheap) qualifier on my comment.

Re: ARM immediate value encoding

#64

Post by ggchappell »

I agree that this clever and useful, but I get the feeling that it could have been more so.

I haven't done much assembly in a while, but I was heavily into it once upon a time, and I recall that values with lots of 1s were useful. There is not quick way to generate those here. This means that we can write a single instruction to set any single bit using an inclusive OR and the proper immediate value, but we cannot write a single instruction to clear any single bit.

The reason I think a bit more cleverness might have helped is that there are so many values with multiple encodings. Anything where the 8-bit value ends with 0 has a different encoding as well. For example, a rotation of 0000 and an 8-bit value of 00000100 gives the same result as a rotation of 1111 and an 8-bit value of 00000001 (right?). Perhaps some of the redundant instructions could have been used to represent things ending in lots of 1s?

Regardless, an interesting and informative post. :-)

Re: ARM immediate value encoding

#65

Post by tlb »

ggchappell wrote: post #64

I agree that this clever and useful, but I get the feeling that it could have been more so. I haven't done much assembly in a while, but I was heavily into it once upon a time, and I recall that values with lots of 1s were useful. There is not quick way to generate those here. This means that we can write a single instruction to set any single bit using an inclusive OR and the proper immediate value, but we cannot wr…

You can get trailing ones by subtracting 1:

0x01000000 - 1 = 0x00ffffff

so you can generate any number of trailing ones with 2 instructions.

Re: ARM immediate value encoding

#66

Post by eckzow »

ggchappell wrote: post #64

I agree that this clever and useful, but I get the feeling that it could have been more so. I haven't done much assembly in a while, but I was heavily into it once upon a time, and I recall that values with lots of 1s were useful. There is not quick way to generate those here. This means that we can write a single instruction to set any single bit using an inclusive OR and the proper immediate value, but we cannot wr…

Clearing an arbitrary bit actually is supported (as mentioned in the article: "you can set, clear, or toggle any bit with one instruction").

The specific details require you to dig a bit past explaining just the immediate encoding, but in the clearing case there's a dedicated instruction for clearing the bit specified by the immediate:

  BIC - Bit Clear (immediate) performs a bitwise AND
  of a register value and the complement of an immediate
  value, and writes the result to the destination register.
As I mentioned in my other post, zero-rotation encodings are gamed out as well (to allow byte repetition).

Re: ARM immediate value encoding

#67

Post by jmpe »

teh_klev wrote: post #58
jmpe wrote: post #33

Earlier quoted context omitted.

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.

Not sure why you're telling me this, I suggested MSP430 to the parent post as an answer for the ISA he was looking for.

Re: ARM immediate value encoding

#68

Post by teh_klev »

jmpe wrote: post #67
teh_klev wrote: post #58

Earlier quoted context omitted.

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.

Not sure why you're telling me this, I suggested MSP430 to the parent post as an answer for the ISA he was looking for.

Ah ok, theatrus2 was the only mention of MSP430 in the discussion under userbinator and in the absence of a "How about " in front of "MSP430?" I assumed you meant "What's a MSP 430?" in reply to theatrus2....but then I should've checked the comment times :)

Re: ARM immediate value encoding

#69

Post by TorKlingberg »

fidotron wrote: post #32
lectrick wrote: post #23

This is clever. However... The problem as I see it with this sort of cleverness is that it's difficult to optimize to this. It leads to quite variable best-case and worst-case scenarios and general unpredictability. As, say, a C programmer and not a compiler designer, you might unintentionally pick lots of values that won't fit into the "immediate" scheme (worst-case). Or you might force your design to use numbers th…

These days if what you're writing is in C then you should really know the behaviour of the architecture underneath. ARM really isn't that hard if you're already thinking like a low level programmer. Things like MIPS were (better) designed for being targeted from higher level languages, but the consequence is a much messier machine language. It's always struck me as amusing that the conventional view is MIPS is minima…

There is lots of C code that is written to be portable, and trusts the compiler to generate optimized assembly. But those are probably ok with spending a couple of extra cycles for some immediate values.

Re: ARM immediate value encoding

#70

Post by ggchappell »

eckzow wrote: post #66
ggchappell wrote: post #64

I agree that this clever and useful, but I get the feeling that it could have been more so. I haven't done much assembly in a while, but I was heavily into it once upon a time, and I recall that values with lots of 1s were useful. There is not quick way to generate those here. This means that we can write a single instruction to set any single bit using an inclusive OR and the proper immediate value, but we cannot wr…

Clearing an arbitrary bit actually is supported (as mentioned in the article: "you can set, clear, or toggle any bit with one instruction"). The specific details require you to dig a bit past explaining just the immediate encoding, but in the clearing case there's a dedicated instruction for clearing the bit specified by the immediate: BIC - Bit Clear (immediate) performs a bitwise AND of a register value and the com…

> BIC - Bit Clear (immediate)

Ah, didn't catch that.

Post reply on HN