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.
www.keil.com/.../armccref_cihcaaid.htm
But why do you want to do this?
www.catb.org/.../smart-questions.html
I had found this and was wondering what it meant: http://www.keil.com/forum/9023/ I do not see any of these options in Keil UVision.
The reason why I want it in arm assembly and not C is that all the other code I have is in assembly.
Imagination doesn't seem to be one of your strong points :(
Having the compiler produce assembler output is easy.
But it may not be what you want.
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.
For a single function, the assembler output from the compiler can be used as a starting step before starting to rewrite the assembler code into something compatible.
Imagination?
It's quite obvious that most C compiler can create an assembler listing.
But there is no one single reason why someone wants assembler output from the compiler. If you only see one reason for it, then you are right - having a bit of lack of imagination ;)
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...
Look carefully: That thread relates to the C51 compiler; you are talking about the ARM compiler - they are not the same!
Au contraire - I can imagine plenty of scenarios where someone might mistakenly believe that this could be a good way to proceed. I can also imagine a few scenarios where it might be appropriate.
Hence the OP needs to explain what his actual goal is...