gcc argument asm macros

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

When calling an asm routine from C the arguments are passed in r25, r24 ... Are there predefined macros in gcc for these? Seems like there would be in case the registers used ever changed in a future version.

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

CirMicro wrote:
When calling an asm routine from C the arguments are passed in r25, r24 ... Are there predefined macros in gcc for these? Seems like there would be in case the registers used ever changed in a future version.
No, but you can roll your own.
I did it badly once when I wanted to write
asm that could be used with both gcc and IAR.

Iluvatar is the better part of Valar.

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

Had a feeling that was the case, but thought I'd check anyway.

Thanks

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

CirMicro wrote:
When calling an asm routine from C the arguments are passed in r25, r24 ... Are there predefined macros in gcc for these? Seems like there would be in case the registers used ever changed in a future version.

Changing those registers means changing the ABI, Application Binary Interface, which is not something that is done lightly. If the ABI changes, then avr-libc will severely break, as those library routines are written mostly in hand-optimized assembly, which requires that the ABI stay static. Changing the ABI would also break many users' code, especially those where there are mixed C and assembly applications.

So, no, the ABI is not going to change anytime soon.

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

Quote:

So, no, the ABI is not going to change anytime soon.

Okay, thanks. That gives me that warm fuzzy feeling :)

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

Eric, is there any preprocessor definition that identifies the ABI version so that programs can check at compile-time if the ABI has changed?

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

So far, there's just one ABI version so consider the lack of any preprocessor
macro a feature indicating ABI version #1. ;-)

The major problem here is that we're not talking about an API but about an
ABI. Thus, linking against any object code that has been compiled for a
different ABI will fail, without the preprocessor even standing a remote
chance of detecting that situation.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dl8dtl wrote:
So far, there's just one ABI version so consider the lack of any preprocessor
macro a feature indicating ABI version #1. ;-)

The major problem here is that we're not talking about an API but about an
ABI. Thus, linking against any object code that has been compiled for a
different ABI will fail, without the preprocessor even standing a remote
chance of detecting that situation.

I think the OP has something less difficult in mind.
He updates his WinAVR. It uses a new ABI.
He recompiles his code, including some assembly functions that take arguments.
His assembly code works because he has used #defined symbols instead of specific registers.
Alternatively, the preprocessor complains:
#if ABI != 1
#error new ABI: rwrite your code
#endif

Iluvatar is the better part of Valar.

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

That was my take on it as well, Michael, especially since his question was about using preprocessor macros. But, Jörg warning is important for the OP to realize.

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

If that is the case, then isn't that what C is for? ;)

If the OP is worried about the ABI changing, then code all functions in C, but if assembly is needed then make a function body inline assembly that uses the parameters that have been passed in C...

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

Quote:
if assembly is needed then make a function body inline assembly that uses the parameters that have been passed in C...

What an evil thing to ask of some someone ;)

Actually I've been reading the help files and tutorials for inline asm. I'll eventually come to terms with it.