Gerhard Fiedler <lists@connectionbrazil.com> wrote:
> Olin Lathrop wrote:
> > > I would like to hear, off list, from anyone with any experience
> > > integrating assembly language modules with HI-TECH PICC C code.
> >
> > It's usually pretty straigh forward. Every compiler manual I've
> > seen has a section called "subroutine linkage", or "calling
> > conventions", or something like that. It describes how arguments are
> > passed to/from subroutines. You do whatever it says in assembler.
> 
> That's one way. Another way is to create almost empty C function bodies
> and put the assembler code inside. Needs an understanding how the
> compiler allocates local variables so that you can use them in your
> assembler code, but allows the compiler to deal with all the issues of
> allocation, linkage etc. on its own. You need to do a bit less on the
> details of how the compiler handles things.
> 
> Adding a few dummy assignments between arguments and local or public
> variables shows you how the compiler does these things. Then you can
> rather easily replicate this in your assembler code.

Why would you go to the trouble to reverse-engineer an interface that's
usually well-documented by the compiler vendor? If you go by just what
you see in a trivial compiled function, you run the risk of making use
of some "feature" that isn't really part of the documented interface
and may change drastically on the next compiler revision, or missing
a hidden assumption or rule that turns out to be important (e.g., which
registers the compiler considers to be caller-saved vs. callee-saved).

Granted, you might write such functions to verify your understanding of
the documentation, but that can't substitute for actually reading it.

-- Dave Tweed
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist