This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

arm assembly - generating of 32 bit constants

Note: This was originally posted on 13th October 2009 at http://forums.arm.com

Hi,

i am searching for an algorithm to load any kind of 32 bit constants. As you know the arm compiler puts in the most cases the constants with some add/mul etc instructions together instead of loading the constant via the program counter out of the "constant pool". The way the compiler generates the constants is not really known to me. Unfortunately I could not find anything about it right now. Does somebody know where i can find something explaining whats the best way is to generate constants. Thx
  • Note: This was originally posted on 13th October 2009 at http://forums.arm.com

    For a generic 32-bit constants you are probably looking at out-of-line loads from a pc-relative literal pool - you cannot directly embed all 32-bit constant values in to an ARM instruction.


    Yes, i know about that. This way i have currently implemented for all constants with the size of over 8 bits. But its definitive not the best and most performant way.

    You can embed *some* constants directly in to many instruction encodings - but these can only encode a limited set of values (8-bits rotated an event number of paces for most data processing instructions in the ARM instruction set).


    Thats what i am searching for :lol: As i need a generator for all various kind of constants there must be some good algorithm for this :)

    For details of all of the instruction set encodings you probably want to get hold of the ARM Architecture Reference Manual - you can sign up for access using the link below:

    [url="https://silver.arm.com/browse/AR570"]silver.arm.com/.../url]


    I´ll check this
  • Note: This was originally posted on 28th October 2009 at http://forums.arm.com

    thx, it proved to be quite easy.... just take the bit representation of the value, check out of how many "8 bit values" it contains of and put it with mov and add (with LSL-shift) together :lol: At least for positive values it works well :)
  • Note: This was originally posted on 13th October 2009 at http://forums.arm.com

    For a generic 32-bit constants you are probably looking at out-of-line loads from a pc-relative literal pool - you cannot directly embed all 32-bit constant values in to an ARM instruction. You can embed *some* constants directly in to many instruction encodings - but these can only encode a limited set of values (8-bits rotated an event number of paces for most data processing instructions in the ARM instruction set).

    Thumb-2 introduces wide-data loads, allowing a pair of instructions to load the high and the low 16-bits of a register.

    For details of all of the instruction set encodings you probably want to get hold of the ARM Architecture Reference Manual - you can sign up for access using the link below:

    [url="https://silver.arm.com/browse/AR570"]https://silver.arm.com/browse/AR570[/url]
  • Note: This was originally posted on 28th October 2009 at http://forums.arm.com

    Yes, that works =)
  • Note: This was originally posted on 13th October 2009 at http://forums.arm.com

    > As i need a generator for all various kind of constants there must be some good algorithm for this

    There isn't really an algorithm - the rule is pretty simple:

    For most ARM instructions the rule is "any 8-bit constant rotated an even number of places" - you simply encode an 8-bit constant and a separate rotation field which is doubled by the hardware. So encoding 0xFF and 0xF000000F would be OK, but 0xE000001F would not (8-bit constant, but requires an odd shift).

    The MVN (move not) instruction lets you invert any of these constants, so you could load 0x0FFFFFF0 using a single instruction in the instruction stream - although requires an explict MVN rahter than embedded the constant in a useful data processing instruction like AND / ORR / etc.

    If you can't encode your constant using these two methods then you are probably down to PC-relative loads from memory, or building a constant incrementally using smaller constants embedded in a sequence of ORR instructions