[AVR] What assembler to use?

I've just been trying to use avra, but it outputs coff or something, so obdump has trouble disassembling it. I am also not sure how to link the result(ihex have no symbol info). So now I believe the thing is next to unusable. Someone correct me if I am wrong, plz. Are there any other, usable alternatives to Gas that have usable macro constructs (+labels)?

Reply to
Johann Klammer
Loading thread data ...

Why do you want an alternative to gas? It does pretty much everything you could want from an assembler, as far as I know.

It is a long time since I have seen much need to write whole programs in assembly - C (or even C++) is just so much more efficient when your task is to write correct, readable, maintainable code in a reasonable amount of development time.

Reply to
David Brown

gas can't handle labels inside macros, and gcc had disappeared nops the last time I wrote sthg timing critical. So I'm looking for alternatives now and then. (I just need a macro assembler)

At closer inspection it seems that avra only supports absolute addresses... so using it together with ld won't work... would have to rewrite parts of it for that...

The weird thing is that they have an example in their repository which consists of multiple asm files, but I can't tell how that would be compiled down to a single hex, as it basically outputs 1 hex for 1 asm.

Reply to
Johann Klammer

Did you declare the gcc nop as volatile?

There are instructions in the manual stating that.

--

-TV
Reply to
Tauno Voipio

Yes it can.

Use ".altmacro" instead of ".macro", and you can make local names and labels using "LOCAL name". You can also use numeric local labels, or \@ for a macro invocation number.

gcc does not remove nops if you write them correctly - but it does remove useless code if it is not marked appropriately. Post some code, and I can see if I can help.

Note that you don't need an assembler if you are mixing assembly and C - inline assembly within the C code is usually sufficient for the few snippets of code that you need in assembly.

Reply to
David Brown

Are you sure that the files are not simply included and the result then processed in a single assembler run?

Reply to
Michael Bäuerle

LOCAL seems to work... I remember having problems with the numeric labels before...nesting?

It's maybe best to just forget about avra then...

Reply to
Johann Klammer

An extended syntax inline asm statement doesn't actually need to be declared volatile if there is no output, so this is okay:

asm ("nop" :::)

However, I think it is good practice to include the "volatile". It is also important to note that compiler can re-order and re-arrange assembly instructions and other code, within certain limitations.

If the OP can post the code he was trying to use, I am confident that we can help him out with the correct syntax. (Of course, he could just read the manual - the avr-libc documentation has a lot of useful information. But sometimes it can be hard to digest.)

Reply to
David Brown

If you have nested macros in your assembly with multiple loops, you are probably over-complicating things.

I'd say so, yes.

But I would also recommend forgetting about gas - and forgetting about writing code in assembly. You need a really god reason to be writing anything more than tiny snippets in assembly these days.

Reply to
David Brown

I think that's incorrect---you can use local numeric labels, or if you use asm() inline assembly, you can use autogeneration with %=

formatting link

Reply to
Przemek Klosowski

What he said.

Many years ago, I did some profiling of an ARM7 project that was written in C using GCC 3.something. The application was spening a significant portion of its time in the BSD network stack's IP checksum function (which was written in standard C).

No problem, thought I, as I wrote my own IP checksum function in ARM7 assembly. It was slower than the C function. After several solid days of work (including a hint from somebody about some pretty obscure ARM7 instruction features), I managed to come up with an IP checksum function that was noticably faster than the standard C one.

A couple years later, there was a update to both the network stack and GCC. I re-ran the comparisons, and my carefully crafted assembly language was now slightly slower than the network stack's C version.

--
Grant Edwards               grant.b.edwards        Yow! My mind is a potato 
                                  at               field ... 
 Click to see the full signature
Reply to
Grant Edwards

If that would be the case (which is in doubt based on other replies), you can always pass a unique label manually on the macro call line even on the most brain dead assembler that supports macros. .

Separate assembly into multiple relocatable objects and then linking/locating into an absolute file was a great thing with slow Intellecs and Excorcisers with floppy drives.

These days all assembly program development is done by cross assembly on a fast PC, in which assembling a whole project into a single absolute file is fast, even after fixing only one assembly line. So just assembly all source files at once into an absolute file.

Reply to
upsidedown

GCC has a pragma that allows you to selectively disable optimization. I use it when crafting code that I need to take total control of execution (for example, bit banging).

JJS

Reply to
John Speth

That is certainly possible. However, it is almost always possible to write code in a way that is correct regardless of the optimisation choices, with barriers, dependency control, volatile, attributes, etc. But correctness is the most important factor, and not everyone is interested in learning the details of how to handle barriers and dependencies in gcc - a couple of pragmas to limit optimisation may be a simple and effective strategy.

Reply to
David Brown

-Os works pretty well even there. I have plenty of bit-banging on GCC, using AVR's and different ARM's, without a hitch.

Of course, in critical parts, it is common sense to read the generated assembly listings.

--

-TV
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.