mix assmbly and c

"If I needed to write a C function with the desired prototype, ... for EVERY ASM function I wrote, it would have definitely taken longer."

I presume you are using "prototype" here in the general English sense of the word: dictionary.cambridge.org/define.asp

Of course, in the specific 'C' sense, you will need a 'C' prototype for each assembler function that you are going to call from 'C'...!

"If I needed to write a C function with the desired prototype, ... for EVERY ASM function I wrote, it would have definitely taken longer."

I presume you are using "prototype" here in the general English sense of the word: dictionary.cambridge.org/define.asp

Of course, in the specific 'C' sense, you will need a 'C' prototype for each assembler function that you are going to call from 'C'...!

"i dont know wether keil supports this..."

Don't you?
You started this thread by quoting the Keil ASM and ENDASM pragmas - that is the way that Keil does it.
See the C51 Manual.

But the whole point if the answers you have received in this thread is to advise you to avoid doing this!

Just because a feature is available doesn't mean that it's going to be a good solution!

Andy quoted me: "If I needed to write a C function with the desired prototype, ... for EVERY ASM function I wrote, it would have definitely taken longer."

The above quote generalizes my statement. The full statement was: "If I needed to write a C function with the desired prototype, generate a SRC compilation and work on templated code for EVERY ASM function I wrote...", which is certainly different.

Explaining further:

Of course every extern C callable function (whether written in ASM or C or any other compiled language) needs a C prototype to correctly load the passed parameters and get the possible return values. This is taken for granted in our above discussion.

My comments against using the SRC directive state that in my opinion using the SRC directive to generate ASM code for a given function prototype (meaning a given set of passed parameters) is less than optimal, since you will usually have to rewrite the parameter accessing code from the bank registers, because that code will depend on the function body, which will obviously not be written in C. My point is that the SRC compilation cycle takes more time than simply write the ASM code directly in .A51 files, using the very well documented C51 procedure call standard.

However, I fully recognize the value of the SRC directive for learning and investigating on how the C compiled code interfaces to other functions.

My comments against using the SRC directive state that in my opinion using the SRC directive to generate ASM code for a given function prototype (meaning a given set of passed parameters) is less than optimal, since you will usually have to rewrite the parameter accessing code from the bank registers, because that code will depend on the function body, which will obviously not be written in C. My point is that the SRC compilation cycle takes more time than simply write the ASM code directly in .A51 files, using the very well documented C51 procedure call standard.

If you do it on a regilar basis and have the "C51 procedure call standard" memorized, I guess you are right.

However, most of us (I guess) only do this a few times a year and the the old adage "better safe than sorry" do apply. Using the proto/SRC method gives a guaranteed result, using the "C51 procedure call standard" allow for mistakes.

Erik

I totally agree with you. The SRC directive can effectively be a template generator, and have its value as a learning tool, as I have said before.

I usually write several functions in assembly for any large project in C51, for both space and performance sake. When you are seeking any of those, the SRC templating method is not indicated, due to the reasons discussed above.

The procedure call standard for C51 is described in the compiler manual, has fixed rules and is very simple. Actually, knowing it helps to write fast C/C function prototypes, not just only ASM/C prototypes.