Hi, I'm looking at calling an ASM routine from some C code. I'd like to pass some parameters into the ASM routine, and have it return a value. I don't believe function arguments are passed on the stack, but am not sure of the general mechanism that is used. Any advice? Thanks David
You're asking about the C51 ABI (application binary interface). I would like to know what the ABI is too. I seem to remember that parameters are always passed in registers or in fixed memory locations (if not a re-entrant function). - Mark
The section your require in the manual is entitled, "Interfacing C Programs to Assembler" - a bit cryptic, I know, but I think you'll find what you're looking for! ;-)
Take a look at the following URL: http://www.keil.com/support/docs/50.htm Jon
A very easy way to do this is to write a skeleton function in "C", the using SRC get the assembly code, cut and paste, insert the assembly guts and voils! you have it. Erik
I agree with you, however, this does not mean you have an authoritative document on the C51 ABI. You can grab a copy of the PowerPC EABI spec. for an example of what an ABI spec. should detail. I'll put the file on my website if anyone cares. Should I write an ABI document for C51? - Mark
This is already well documented in the C51 User's Guide. Jon
"This is already well documented in the C51 User's Guide." One thing missing from the User's Guide (and noted some time back on this forum) is how C51 implements returning a struct from a function. Also, is there a definitive statement of how C51 handles assigning a larger value (eg, char, int) to a bit? We've had some guesses & opinions at http://www.keil.com/forum/docs/thread1315.asp - but what is the defined behaviour?
A struct that is returned from a function:
struct bob_st func (void) { . . . }
void func (struct bob_st) { . . . }
Variables of type bit and bit fields are not the same thing. bit types have a true or false state and can only have the values 0 or 1. When you assign a value to a bit the compiler determines the TRUTH of the value. In other words non-zero values (whether they are bit, char, int, long, or float) have a bit value of 1. Zero values have a bit value of 0. bit fields are a different animal entirely. A bit field has a value from 0 to (2^(number of bits) - 1). When you assign a value to a bit field, the compiler must determine the AMOUNT of the value. If the value is less than the maximum number that can be represented, there is no problem. If the value is larger than the bit field, the compiler must coerce the larger value into the bit field. This is done using the exact same method that is used if you were to assign a long to a character--the additional bits are lost and the original value is masked down to the number of bits represented by the bitfield. On a slightly different note, bit types may have a memory type associated with them, however, this the hardware limits where bits may be located, only the DATA and IDATA memory types may be used with bit variables. Jon
So there we have it. Keil C51 treats bit variables are booleans. In the thread Andrew referenced (http://www.keil.com/forum/docs/thread1315.asp), I offered an opinion regarding what could be considered as the logical progression of C's integer object narrowing rules if one were to view bits as a "native" C integer as opposed to a "non-native" boolean. My real intent in that thread was to convey a hint to those who, like myself, reuse code for other 8051 compilers or other MCU compilers that support non-ANSI/ISO extensions. Other vendors that support bit objects can implement bits according to their own interpretation (and they do). With any language extension, bit variables included, I have found it beneficial to use them in an explicit manner and/or macro'ize them so their usage is clear, trying to avoid any possible ambiguity in the event that the code is reused -- just like you might do explicitly for any "formal" integer-to-boolean conversion between standard C data objects.