[AVR] What assembler to use?

On 2018-06-18, David Brown <david.brown@hesbynett.no> wrote:

> 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.

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 ...
                              gmail.com            

On Mon, 18 Jun 2018 09:07:02 +0200, Johann Klammer
<klammerj@NOSPAM.a1.net> wrote:

>On 06/17/2018 07:29 PM, David Brown wrote:
>> 
>> 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.
>> 
>gas can't handle labels inside macros, 

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.
.  
>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. 

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.
 

> 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.

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

On 18/06/18 18:39, John Speth wrote:
>> 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.
> 
> 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).
> 

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.

On 18.6.18 19:39, John Speth wrote:
>> 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.
> 
> 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

-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