I need to do an entire project in mostly-time critical code. Using assembly seems like a good idea. I've seen quite a few example assembly files and such which have an "Intel" feel to them. I know there is a gas assembler used by gcc for AVR, but it's "AT&T" style which I've always hated(namely because it's not designed for human writing).

Anyway, apparently the assembler most people use is called avrasm2.exe. One problem with that: I use Linux, especially when working with low-level projects. I've heard of a workaround with using Wine to run avrasm2, but that sounds just plain horrible.

Is there a freely available/open source AVR assembler which is similar to avrasm2 available for Linux?


closed as off topic by Leon Heller, Dave Tweed, placeholder, Anindo Ghosh, Brian Carlton Apr 26 '13 at 15:55

Questions on Electrical Engineering Stack Exchange are expected to relate to electronics design within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ What's so horrible about wine? It's just a compatibility library that allows Windows binaries to run directly under Linux. It isn't like setting up a separate VM or something. \$\endgroup\$ – Dave Tweed Apr 26 '13 at 10:49

So I need to do an entire project in mostly-time critical code. So, using assembly seems like a good idea.

That is a false proposition. Are you saying there is not a single instruction sequence in the code that runs only once? If the code spends 90% of its time in 10% of the code, then most of the speed benefit in writing it in assembly language will be that which was spent on that 10% lines of code. Rewriting the remaining 90% will bring only diminishing returns.

Now the previous applies to speed. Code size doesn't follow the 90/10 rule: a program spends 100% of its size in 100% of the code. A word saved anywhere along program's length makes it a word shorter. The best way to justify coding everything in assembly is that it has to be as small as possible. But that may preclude it being as fast as possible. For instance, you don't get to unroll loops if the code is to be as small as possible. Or pad functions or other branch targets to align them with cache lines.

Converting to a different style of assembly language is trivial. It's nothing like, say, translating a Haskell program to C. There is no semantics involved, or even deep syntax. It's transliteration, not translation, so get over it. The GNU assembler syntax is perfectly usable for human coding and the nice thing is that it brings a certain kind of consistency across different architectures, which you will appreciate if you move from ARM to MIPS, to SPARC, to ... Anyway, why would you expect Intel syntax for a CPU that isn't Intel x86?

Rant: Intel syntax? Come on, it has insipid verbiage in it like DWORD PTR which can be condensed down to a one letter suffix. Intel's x86 syntax is the COBOL of assembly language programming.

  • \$\begingroup\$ time critical as in, AVR can barely handle the timing requirements, so I have to count clock cycles. I've used assembler before(x86 and some ARM). And yea, I know that my "intel" style phrase now (after more research) is just wrong... Still gas is definitely not designed for human writing (Where Intel vs AT&T means the order of registers is reversed, It isn't so in AVR) \$\endgroup\$ – Earlz Apr 26 '13 at 14:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.