Gerhard Fiedler wrote: > As I read it, Olin gave two advices: RTFM (which I assumed as being the > obvious thing and not needing any comment) and then how to proceed and > integrate assembler code with C code. > > Olin: > > > It describes how arguments are passed to/from subroutines. You > > > do whatever it says in assembler. > > To me it seemed that Olin was talking about integrating assembler code as > pure assembler files, where the assembler code creates everything that's > necessary to integrate with the C generated code. This includes the > calling conventions (calling assembler routines from C and calling C > functions from assembler), but includes a lot more that needs to be taken > care of (most notably the linker commands). You would have in your > project C files and assembler files with public symbols and link them > together. That's what I called "one way". > > What I called "another way" is that you create C files with rudimentary > C function bodies (that declare the arguments and local variables in C) > and put your assembler code inside the C function body. This has the > advantage that you can use the compiler's help with documenting and > checking the function arguments with all callers, allocation of local > variables, call tree creation, generating the appropriate linker commands > and so on. Depending on what you are doing in the assembler code, this > may be easier than creating everything in assembler. You also can switch > between assembler and C and do whatever is more convenient or efficient > in either part. In the project you only have C files, some of which > contain any amount of assembler in their function bodies. OK, then let's talk about it. I don't have any experience with this particular C compiler, but I have used both approaches in the past with other compilers in embedded applications. I don't think that embedding assembly language inside C functions is any less complicated than the "pure assembly" approach. With inline assembly, there are different (and usually more) rules than the ones associated with subroutine linkage, and they tend to vary more from compiler to compiler. Some compilers give a lot of assistance with accessing local/global C symbols from the inline assembly, some give almost none. Whether using inline or pure assembly, the linker issues are pretty much the same, regardless of whether you're using an IDE or command-line tools. You list the modules you want, and they get linked in. After all, by the time the code gets to the linker, it's all object code anyway. Yes, there are additional statements in the assembly source relating to external/global symbols and memory segment names (things that the C compiler generates by default), but that isn't a big deal. As long as you're creating proper C header files for your pure assembly functions, the argument checking, etc. that the compiler does is also the same. So, as I see it, the pure assembly approach is usually cleaner and easier to port among compilers, and avoids all unnecessary overhead in subroutine linkage. The inline assembly approach can be useful in some cases, but it usually disables most of the compiler optimizations (especially with regard to register allocation) and tends to be less portable. IIRC, the OP's question related specifically to interrupt handlers. Writing an ISR in pure assembly has huge benefits over doing inline assembly inside a C function, because with the latter, the C runtime library must save a large amount of context and set up the full runtime environment for what is essentially a new C thread, call the function and then restore everything afterward. A pure assembly ISR can save only the resources it needs to use, do its thing, restore and return directly to the mainline code. The difference in performance can easily be an order of magnitude or more. -- Dave Tweed -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist