GNU assembler and symbolic names

[czielinski9]

Posted on July 30, 2009 at 19:41

GNU assembler and symbolic names

[czielinski9]

Posted on May 17, 2011 at 13:18

Hi

Because of frequency and complexity interrupt handle routine I must write it in assembly language (Raisonance Ride7 and GNU toolchain). In this routine I want to access a number of external variables, so it's addresses need to be shared within routine. I know there is ability to pass the parameters through registers, but in that case at least one processor register stay unusable. Is there any other way? Is there any way to make the C preprocessor symbolic names ''visible'' within assembler sources? Best regards

[czielinski9]

Posted on May 17, 2011 at 13:18

Preferably both, but I'm afraid it's impossible. Macros would be

very useful...

[st3]

Posted on May 17, 2011 at 13:18

Quote:

Is there any way to make the C preprocessor (sic?) symbolic names ''visible'' within assembler sources?

Do you really mean pre-processor there; ie, names created with #define ? Or do you mean compiler symbols?

[vincentchoplin9]

Posted on May 17, 2011 at 13:18

Hi,

If I understand your question correctly, you just want to access a global variable declared in C from an assembler routine. Is that what you mean? If yes, then you just need to declare the variable as extern at the start of your assembler file, or in an include, like this: .extern mydata You can find examples of that in the sources of the startup and library files in this directory: \lib\ARM\... Note that you must be careful that your assembler routine accesses the variable using the correct type, size, endianness, etc. The assembler does not check that for you like the compiler would. Finally, note that if the ISR is complex, then probably the compiler would do a better job than you at writing it. Here is how I would proceed: 1. write the ISR in C and validate it except for speed issues. activate speed opti mode and validate the ISR again, still ignoring speed issues. 2. activate the 'save temp files' option, that will tell the compiler to keep the temporary assembler file that it generates during compile. 3. in your project, replace the C file referenced in 1. by the asm file referenced in 2., and optimize it by hand if you see that you can do better than the compiler This is probably the fastest, safest and most efficient way to proceed in your situation. I hope it helps. Best Regards, Vincent

[czielinski9]

Posted on May 17, 2011 at 13:18

VincentC, andreas1,

tkanks for your help. Of course, a symbolic names works as VincentC wrote, especially those declared in the same module, even without the ''.extern'' directive. I don't uderstand why it doesn't work for me before i I've posted my first message on this forum. Very strange... Thanks for your optimisation guidelines. I tried compiler abilities, but it too often use the memory for storing data, regardles of register variables declarations. So i wrote whole procedure in pure assembler and the result seems to be very interesting. If you want to see it, I'll share it with pleasure. My experience with GCC isn't so big, but it's my first, based on ARM project. I hope I will learn it better. Thanks again. Best regards.

[vincentchoplin9]

Posted on May 17, 2011 at 13:18

Also, of course there are macros in the GNU assembler. They don't use the same syntax as the C macros (''.if(something)'' instead of ''#if something'', etc.) but they provide pretty much the same features.

See the assembler files provides in Ride for examples, and of course the assembler doc. ;)

[andreas2]

Posted on May 17, 2011 at 13:18

Note that the GNU C preprocessor can be used with assembly files as well, albeit in a somewhat limited fashion. Just name your assembly files with extension .S instead of .s, or pass ''-x assembler-with-cpp'' to gcc if your file system doesn't preserve case.

I often find it more convenient to use inline assembly instead of a separate assembly file. But then it's often about a few lines of code that can't be implemented in C (access special instructions, OS kernels, cycle exact timing, ...). I wouldn't want to write a large function in pure assembler anyway. The compiler does that job way better and my efforts can instead be used for algorithmic optimizations which often give far more bang for the buck. If you really need to save those cycles, well... Profile, find a hot spot where the compiler generates sub-optimal code, and rewrite that little bit in inline assembler, based on the compiler output. But try again with the latest compiler before you do.

[andreas2]

Posted on May 17, 2011 at 13:19

If you made a significant improvement from the compiler generated code, it would be interesting too see both the C and the asm implementations for comparison.

[czielinski9]

Posted on May 17, 2011 at 13:19

With pleasure, as soon as I'll be back from my holiday. Tomorrow I'm going

on mountains :) Best regards