Post by thread:[PIC] using a Basic or C compiler with MPASM

Hopefully this question will generate some interesting and useful replies. I really would like an answer to this, and I suspect others might, as well, so here goes. We have an application written in MPASM running on the 18F452 (at the moment) - nothing terribly elaborate, reads some A/D channels, does some digital I/O, uses the SSP to communicate with peripherals, and talks to a PC using the UART. Also, the program has some limited decision making code - to save communications bandwidth it makes a series of measurements, does some calculations, and returns simple ON/OFF YES/NO or Numeric values as answers to simple English-language queries. This is working OK for the moment, but it isn't a static product. From time to time we want to add functions to the basic design, or change the way some part of it operates for a specific application. The question has been asked (of me, by the owner) if it wouldn't be more efficient to do these add-ons in a high level language. And of course it would be more efficient if the whole thing had been written in a compiled language from the beginning, but it was conceived a single-purpose box - only later was it realized that it had many other potential applications and the modifications started. So my question is - does anyone have experience of a compiled language which produces code which can co-exist with direct MPASM code? That is, that could compile a procedure into MPASM source (I guess) which could then be easily integrated with the existing (unchanged) MPASM code? I have seen the output (examples) of some PIC compilers, and they seem to put an operating environment into place in which their code is intended to run. The problem with that is that the existing MPASM code doesn't have the same "shell" or assumptions about the hardware, and might not be able to operate with them without changes. I know it would make far more sense to rewrite the application in the compiled language, and given the time I will do just that. But for now the question is what I asked - has anyone done this and using which product(s), and with what success (or lack thereof)? Thanks, Roy J. Gromlich Renaissance Technologies 5000 Ritter Road Suite 202 Mechanicsburg, PA 17055 717-691-7090

Roy J. Gromlich wrote: > So my question is - does anyone have experience of a compiled language > which produces code which can co-exist with direct MPASM code? That is, > that could compile a procedure into MPASM source (I guess) which could > then be easily integrated with the existing (unchanged) MPASM code? I hope you get more inspiring answers... I don't know of any C compiler that outputs MPASM code. They all implement their own tool chain up to the linker (some with separate stand-alone tools, some integrated). Maybe one way could be to define binary interfaces between the MPASM code and the C code, with fixed addresses and address ranges where jump tables are located and variables are to be placed. You'd get two hex files that you would have to merge. Still quite an endeavor -- I guess I wouldn't do it. Gerhard

On Tue, 12 Apr 2005 20:21:41 -0300, Gerhard Fiedler wrote: >Roy J. Gromlich wrote: > >> So my question is - does anyone have experience of a compiled language >> which produces code which can co-exist with direct MPASM code? That is, >> that could compile a procedure into MPASM source (I guess) which could >> then be easily integrated with the existing (unchanged) MPASM code? > >I hope you get more inspiring answers... I don't know of any C compiler >that outputs MPASM code. They all implement their own tool chain up to the >linker (some with separate stand-alone tools, some integrated). > The closest you could get to that would be the compiler's listing file. I think it would take quite a bit of work to turn it into code that could be assembled. It's possible, though, that a lot of the work could be automated. Another possibility would be to use block 'asm' / 'endasm' pragmas to embed existing assembly functions within a C 'wrapper' function. Interfacing the parameters and return values could get really messy, though. Regards, Bob

>>> So my question is - does anyone have experience of a compiled >>> language >>> which produces code which can co-exist with direct MPASM code? Any C compiler worth paying for should include a number of ways of "co-existing" with ASM code. The method you mention; editing of an output .ASM file, is perhaps the least desirable method, since that "editing" phase is usually manual. There is also: 1) documentation of the C function calling conventions sufficient to allow ASM functions to be written so that they can be called from C programs. This also usually means that C functions can be called from assembler, but some C functions may depend on initialized global state, so it tends to be best in "mixed" situations to make main() be a C program. 2) documentation of C startup requirements and initialization so that any C function can be called from a pure assembler program, or so that the startup code can be entirely replaced by your own C or ASM code. On "big" processors, this sort of thing tends to become important when you want code to run from ROM, for example. 3) inline assembler code. Hopefully fancy enough to access symbols defined by C; gcc for big processors has amazingly baroque syntax so that inline assembler can access local variables even if they're in registers. Any C compiler that produces intermediate files usable by the standard microchip linker ought to be able to do simple forms of coexistance without even much awareness on either side. Functions with no arguments or return values, global variables, or ISRs all ought to be writable in any languauge without much special handling (some compilers modify variable and function names.) Sorry, I don't know which of these might or might not apply to the plethora of PIC C compilers... BillW

Gerhard Fiedler wrote: > Roy J. Gromlich wrote: > >> So my question is - does anyone have experience of a compiled language >> which produces code which can co-exist with direct MPASM code? That is, >> that could compile a procedure into MPASM source (I guess) which could >> then be easily integrated with the existing (unchanged) MPASM code? > > I hope you get more inspiring answers... I don't know of any C compiler > that outputs MPASM code. They all implement their own tool chain up to the > linker (some with separate stand-alone tools, some integrated). On second thought... the obvious first choice for investigation would be the Microchip C compilers. I don't know them, though, and I think they don't have a compiler for the mid-range processors. Regarding reworking a compiler's list file output: not every compiler creates one; mostly the ones that have a tool chain of standalone programs. With the one I know best (Hitech), the difference is not so much in the opcodes and the assembler code itself; that is pretty much compatible. What you would have to "translate" are all the pseudo ops, mainly the instructions about code and data placement. In any case you need a /well/ documented compiler. Gerhard

William Chops Westfield wrote: > >>> So my question is - does anyone have experience of a compiled > >>> language > >>> which produces code which can co-exist with direct MPASM code? > > Any C compiler worth paying for should include a number of ways of > "co-existing" with ASM code. The method you mention; editing of an > output .ASM file, is perhaps the least desirable method, since that > "editing" phase is usually manual. There is also: > > 1) documentation of the C function calling conventions sufficient to > allow ASM functions to be written so that they can be called from > C programs. This also usually means that C functions can be called > from assembler, but some C functions may depend on initialized global > state, so it tends to be best in "mixed" situations to make main() > be a C program. In XCASM (the back end for the XCSB compiler) there is a directive that defines where formal parameters are located in RAM. The formal parameters are defined symbolically (i.e. as variables global to the assembly source) and the type of the parameter is determined by the way the actual variable is defined. If your asm subroutine is defined as fred_arg1 .ds 1 fred_arg2 .ds 1 fred_result .ds 1 fred movf fred_arg1, w addwf fred_arg2, w movwf fred_result return converting this for use by XCSB would be simply a case of declaring fred as a function like this: fred .func .fastcall, fred_result, fred_arg1, fred_arg2 You would then be able to call fred directly from within XCSB calling an XCSB function from assembler is even easier if this is old existing assembler source var1 .ds 1 var2 .ds 1 var3 .ds 1 movf var1, w addwf var2, w movwf var3 calling the following XCSB function: proc SUM(byte A, byte B) return A + B endproc The above assembler could simply be rewritten as: var1 .ds 1 var2 .ds 1 var3 .ds 1 .let var3 = SUM(var1, var2) Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use

Bob Barr wrote: {Quote hidden}> On Tue, 12 Apr 2005 20:21:41 -0300, Gerhard Fiedler wrote: > > >Roy J. Gromlich wrote: > > > >> So my question is - does anyone have experience of a compiled language > >> which produces code which can co-exist with direct MPASM code? That is, > >> that could compile a procedure into MPASM source (I guess) which could > >> then be easily integrated with the existing (unchanged) MPASM code? > > > >I hope you get more inspiring answers... I don't know of any C compiler > >that outputs MPASM code. They all implement their own tool chain up to the > >linker (some with separate stand-alone tools, some integrated). > > > > The closest you could get to that would be the compiler's listing > file. I think it would take quite a bit of work to turn it into code > that could be assembled. It's possible, though, that a lot of the work > could be automated. > > Another possibility would be to use block 'asm' / 'endasm' pragmas to > embed existing assembly functions within a C 'wrapper' function. > Interfacing the parameters and return values could get really messy, > though. In XCSB using wrapper functions is trivial since the embedded assembler source can access parameters, local variables and global variables directly without worrying about name spaces or name mangling e.g. // global definition byte A, B proc fred(byte X, byte Y) asm_start movf X, w addwf A movf Y, w addwf B asm_end endproc Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use

> I hope you get more inspiring answers... I don't know of any > C compiler that outputs MPASM code. They all implement their > own tool chain up to the linker (some with separate > stand-alone tools, some integrated). I believe bknd has the ability to output asm code... --- James Newton: PICList webmaster/Admin spam_OUTjamesnewtonTakeThisOuTpiclist.com 1-619-652-0593 phone http://www.piclist.com/member/JMN-EFP-786 PIC/PICList FAQ: http://www.piclist.com