armasm | ARM inline assembler for Python

If you must use a counting-loop delay, you must at least declare the control variables volatile to be sure they will not be optimised away:

The ARM64 orr immediate instruction takes a bitmask immediate, see Range of immediate values in ARMv8 A64 assembly for an explanation. And GCC has a constraint for an operand of this type: L.

So I would write:

Short answer: welcome to GCC. Do not bother optimizing anything while you are using it. And Clang isn't better either.

Secret tip: Add ARM and ARM64 components to Visual Studio, and you'd be surprised how well it works. The problem is however, it generates COFF binary, not ELF, and I haven't been able to find a converter.

You can use Ida Pro or dumpbin and generate a disassembly file and it look. like:

@Jester in the comments recommended either to use i constrain to pass larger immediates or use real C variable, initialize it with desired value and let the inline assembly take it. This sounds like the best solution, the least time spent in the inline assembly the better, people wanting better performance often underestimate how powerful the C/C++ toolchain can be at optimizing when given correct code and for many rewriting the C/C++ code is the answer instead of redoing everything in assembly. @Peter Cordes mentioned to not use inline assembly and I concur. However in this case the exact timing of some instructions was critical and I couldn't risk the toolchain slightly differently optimize the timing of some instructions.

Bit-banging protocols is not ideal, and in most cases the answer is to avoid bit-banging, however in my case it's not that simple and other approaches didn't work:

• SPI couldn't be used to stream the data as I needed to push more signals, and have arbitrary lengths, while my HW supported only 8-bit/16-bit.
• Tried to use DMA2GPIO and had issues with jitter.
• Tried IRQ handler, which is too much overhead and my performance dropped (as you see below there are only 2 nops, so not much space to do in the free time).
• Tried pre-baking stream of bits (including the timing), however for 1 byte of real data I had ended up saving 64bytes of stream data and overall reading from memory so much was much slower.
• Pre-backing functions for each write value (and having a lookup table of functions, for each value write) worked very well, actually too fast because now the toolchain had compile-time known values and was able to optimize it very well, my TCK was above 40MHz. The problem was that I had to add a lot of delays to slow it down to desired speed (8MHz) and it had to be done for each input value, when the length was 8-bits or less it was fine, but for 32-bit length it was not possible to fit into the flash memory (2^32 => 4294967296) and splicing single 32-bit access into four 8-bit accesses introduced a lot of jitter on the TCK signal.
• Implementing this peripheral in FPGA fabric, would allow me to be in control of everything and typically this is the correct answer, but wanted to try to implement this on a device that has no fabric.

Long story short, bit-banging is bad and mostly there are better ways around it and unecesary using inline assembly might actually produce worse results without knowing, but in my case I needed it. And in my previous code was trying to focus on a simple question about the immediates and not go into tangents or X-Y problem discussion.

So now back to the topic of 'passing bigger immediates to the assembly', here is the implementation of a much more real-world example:

https://godbolt.org/z/5vbb7PPP5

I don't have Kiel handy but doesn't really matter, you didn't provide enough information (what is your target architecture/core) and not all of this is well documented by arm.

So generic thumb

All tool "chain" linkers have to deal with function calls or other to external resources, you will see instructions like bl encoded as a branch to self or branch to zero or some such incomplete instruction (certainly for external labels). The tangent here is that some versions of clang appear to sometimes encode for a local address and sometimes not (at the assembler level). But when linked the offset/address is patched up (as in this case).

A generic clang (all targets, default x86 host) 3.7 at the object level gives the right instruction. 3.8 doesn't. That appears to be the time this change happened. Clang 10 generic doesn't but a hand built clang 10.0.0 specific to one target, does give the right answer at assemble time.

All of this is a tangent because that is at assembly time not final output. When linked you get the right answer (thus far, the OP may have other cases where it didn't).

The linker should take care of that automatically. If you objdump -dr the object file, you should see a bl with an R_ARM_THM_CALL relocation, such as: