Porting AVRStudio assembler to GNU assembler

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello GNU-gurus,

I am using the GNU C compiler and I have a bunch of existing assembler code (about 3000 lines worth) that are written in AVR Studio. I would very much like to call those assembler routines from C, however when I include them in the GNU makefile the GNU assembler complains a great deal.

It seems the GNU assembler does not recognise the various AVRstudio assembler directives, variables, etc. For example, to load the low byte of a 16-bit number into a register, in AVRstudio one will do: ldi r16,low(3000), whereas the GNU assembler expects ldi r16,lo8(3000). Similarly there are differences in naming technique (def versus #define) etc etc etc.

Does anyone have any tips on how to get past this? I'm really hoping I don't have to recode my entire assembler library!

Thanks very much.

Frank.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Frank,

I was confronted with the same problem. I think you have to go through all your code in order to adjust the call conventions to the subroutines (parameters etc) and you have to define also all variables an other way.

The main things you have to do, you have allready mentioned.

AVR-ASM GNU-ASM
- low() lo8()
- high() hi8()
- var: .byte 3 .lcomm var, 3
- var: .db 4,5,6 .byte 4,5,6
- var: .dw 1,2,3 .word 1,2,3
- .def #define

Be aware that all include files have to be included by #include instead of .include. That's because of the several passes the assembler uses to compile the source. The first ist the preprocessor pass. There alle the # direktives are handled. Afterwards the assembler dose its work. At this stage the . direktives are processed. So if you include a file by .include all the directives with # are no longer processed. For example a #define in a file that was included by .include will not be processed.

The second main thing you should be aware is, the you must use // or /* */ after a #define instead of ;. That's because the preprocessor, that looks at a line with # interprets all except the known C comment.
So if you write the lines like this

#define Val1 8 ; der erste Wert
#define Val2 4 ; der zweite Wert

.byte Val1 | Val2

you would get two bytes with the value 8 and 4 instead of one with the value of 0xC

There are many things you have to be aware, but I would't describe them all here. It took me a long time, to understand all the points to get my assembler sources work together with C. If you have any question don't hasitate to send them to me.

Olaf

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Frank,

if you want to save a lot of work then try to write some porting macros which simple change the meaning of some - may be all - AVR-asm to GCC-asm syntax.

You even can redefine the include directive, but you must run cpp, the preprocessor, twice.

try this

#define .include #include
#define low(x) lo8(x)
...
and so on

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I ahove the same issue.

It would be nice if you could convert  ATMEL assembler to GNU assembler with a few REPLACE ALL edits.

 

Maybe some enterprising person can even produce a conversion program. I would buy it for $50!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you starting to real all AVRfreaks posts from the beginning?  This is the second response to a dead thread from 2001 today.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
This is the second response to a dead thread from 2001 today.

HA Ha - indeed: https://www.avrfreaks.net/comment...

 

But, on the actual topic, I wonder if it would be easier to make a source-level translator, or to just disassemble the object generated by one into the other ... ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
But, on the actual topic, I wonder if it would be easier to make a source-level translator, or to just disassemble the object generated by one into the other ... ?

 

Neither?

 

Of course all app/projects are different, and would have different goals.

 

If an extensive ASM app, what would be the impetus and/or payback from changing ASM toolchains?

 

If not an big app, then how much editing could there be?

 

Which direction do you want to translate?  Atmel assembler to GAS is probably straightforward; perhaps a bit more onerous if e.g. 1000 lines of macros.

 

Vanilla GAS to Atmel assembler also.  But in an extensive app, there may be a number of the advanced GAS constructs that might be difficult if not impossible with a simple translation.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PaulWDent wrote:
Maybe some enterprising person can even produce a conversion program.
There's one, Brad, who is very experienced in both variants of AVR assembly language (Atmel, GNU)

https://www.avrfreaks.net/forum/org-using-gcc-gas by AtomicZombie

in the context of

https://www.avrfreaks.net/forum/xmega-cranks-out-ntsc-color-and-digital-stereo-sound

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PaulWDent is heading for a ban!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly