Olin Lathrop wrote: >> That's wrong. The PICC linker does some very specific handling of the >> local variables that is quite different from allocating an array for >> that data. > > You didn't say you were using a non-standard linker. My comments apply to > the MPLAB linker. Well, the whole discussion was about integrating assembler code with the PICC compiler. So of course I was talking about the PICC linker. You wouldn't want to try to integrate the PICC compiler with the MPLAB linker. > So what different handling of local variables does this linker do? It > shouldn't care about automatic variables since these are created on the data > stack and kept track of by the compiler. Since PICs don't provide native commands for handling a data stack, most PIC compilers don't use a data stack like normal C compilers do. Bob already explained the basics of what most PIC compilers do: they use a static, compiled stack. Using my method of integrating assembler with C, one can take advantage of the compiler's capability of tracking the local storage needs of every function and allocate local storage at a location where it uses minimal space and is guaranteed to never overwrite local storage of functions higher up in the call tree nor be overwritten by functions further down in the call tree. This optimal location of the local storage of course changes when the call tree changes, and thus is something that's nice to have handled automatically. >> RTFM and try to understand the call tree in the map file. Then maybe you >> begin to understand one of the reasons why I brought up this whole >> thing. > > I'm not going to read the manual for a linker I don't use just to have this > conversation. Of course not. But if you don't, you could consider being a bit more careful with attributes like "silly". It seems you didn't know what I was talking about when you called it "silly". Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist