Re: arm assembly examples

Thanks Lasse. I'll give it a try.

Hul

Lasse Langwadt Christensen snipped-for-privacy@f> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:

(I can't answer to the original article.) This doesn't sound very professional. Random test code doesn't cut it. You have to make comprehensive tests for your assembler. If you have tests where your assembler generate binary code, you only have to disassemble that binary code using a different tool, e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare. Differences have to be investigated. Do not assume GNU has no defects.

See also

Groetjes Albert

Given his stated use, I would imagine a simple comparison of binaries from <whatever> tool was used, previously, against the output of the new tool would give a high degree of confidence for the sort of code that he's encountering.

It's unclear how reliant he/they will be on the tool; if "learned eyes" will be available to analyze any unexpected behaviors from the execution of the code, then "close enough" (for a subsequent revision) may be good enough.

We developed an ASL for a project (early in my career) that leveraged COTS tools but in user-friendlier ways. It was not uncommon to discover shortcomings in the "code" generated. But, rather easy to spot those problems and "fix" our tool, accordingly (within hours of discovering the problem).

While this *felt* like a huge kluge, the end users were tickled to have the programmability as the problems tended to be corner cases that they seldom encountered (and, thus, could pretend didn't exist).

Of course, our rapid turn-around on support made even THOSE tolerable (it got to be more a case of "Hey! You won't believe what I discovered, today!" instead of "What a frigging piece of crap!") tool

I can tell you that comparing binaries where there is a byte inserted here and there is much more unpleasant than comparing disassemblies. So I don't thing that will work, because contrary to popular believe very few assemblers determine exactly how the binary looks. In fact I believe the one I've written is the only one. Assemblers generate different outputs nowadays deciding whether a jump is short or long, or whether an offset can be in a byte, what opcode to use as a nop, or even more "clever" things. A case in point, the 8086 and successors contains some 50 instructions that are one byte duplicates of longer regular instructions. AMD succesfully hijacked 16 of those to provide a 64 bit i86. This added even more ambiguity, because a 0x48+## prefix (or 0x40+## prefix for

32 bits code) will be routinely used by compiler writers, and it may not (will not) be removed if unnecessary.

For the arm the situation is maybe not that extreme, however built-in shifting and built-in conditionals may make it difficult to assess ARM instructions.

I hope your customers are not into mission critical, life critical applications, but hay. It is pretty "easy to spot those problems" like airplanes falling from the sky.

Groetjes Albert