I am using Keil uVision4 with an STM32VL Discovery board with an onboard ARM chip. I am wondering if their is anyway inside of Keil uVision4 to convert some C code I have for am external peripheral to ARM Assembly language.
Thanks in advance... I hope this is enough information.
If you have a project written in assembler, that assembler code will probably use its own rules for parameter passing etc, than what the compiler will create.
Now why would you want to use something different? There is a perfectly good calling convention created/recommended/supported by ARM. It's very well documented and a basic appreciation of it is incredibly useful for someone who wishes to understand the assembler/compiler.
People who write a few routines in assembler and the main bulk of an application in C would have much to gain by following the calling conventions etc (ABI) that ARM have published.
Someone who do write a full application in assembler, would have a very limited reason to care about the ARM ABI. Such people aren't likely to write just 96% in assembler and then hope to integrate this code with 4% written in C. So there are direct advantages from skipping standard stack frames and use whatever calling convention that fits best for every single function implemented. Not only that - it's quite common to write functions with multiple entry points to make use of common code sequences without the cost of a call/return and without code duplication.
By the way - why did you put an emphasis on "you"? There was no "me" used in my previous post.
@Per,
Smart answer!!!
So there are direct advantages from skipping standard stack frames and use whatever calling convention that fits best for every single function implemented. Not only that - it's quite common to write functions with multiple entry points to make use of common code sequences without the cost of a call/return and without code duplication.
There may be advantages on some processors in using a different calling convention, but on the ARM?
Doing it using the pattern whatever calling convention that fits best for every single function implemented is, quite frankly, courting disaster. The maintenance of such code is awkward at best. I have seen, and had to maintain, large projects of assembler code done in such a manner. Keeping track of register usage in nested function calls was not easy.
it's quite common to write functions with multiple entry points to make use of common code sequences without the cost of a call/return and without code duplication
Common? Really?
It was a question to 'you' as in 'dear reader'.
Yea, right. A sheep is so easy to recognise.
I don't see any significant advantage in maintaining a uniform call convention under these circumstances. It was difficult for you - does it make it unwise? Ho by the way, there is really no need to demonstrate your potty mouth tendencies when somebody fails to agree with you, yes, S Smyth?
I don't see any significant advantage in maintaining a uniform call convention under these circumstances
You didn't actually read all of what was written, did you.
Why don't you wait for someone else to respond then you can agree with them.
It's obvious you do prefer to debate other people more than you care about considering actual arguments.
IF the OP's assembler code did, indeed, observe the ARM ABI, then it would be easy to interface with 'C' - so there would be no point in converting the 'C' to assembler!
Just one reason that it helps to know why the OP wants to do this...
?
Imagination doesn't seem to be one of your strong points :(
It has been a true challenge to find a programmer with the type of imagination that can manipulate logic to show 2 plus 2 does indeed equal 5.
Behold, one such programmer has been found.
So you should be a little less hasty in your accusations of lack of imagination!