Searching \ for '[PIC] using a Basic or C compiler with MPASM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=basic
Search entire site for: 'using a Basic or C compiler with MPASM'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] using a Basic or C compiler with MPASM'
2005\04\12@134827 by J. Gromlich

flavicon
face
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


2005\04\12@192150 by Gerhard Fiedler

picon face
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

2005\04\12@220236 by Bob Barr

flavicon
face
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

2005\04\13@003409 by William Chops Westfield

face picon face
>>> 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

2005\04\13@054229 by Gerhard Fiedler

picon face
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

2005\04\13@111748 by Sergio Masci

flavicon
face
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





2005\04\13@112440 by Sergio Masci

flavicon
face
Bob Barr wrote:

{Quote hidden}

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





2005\04\13@144611 by James Newton, Host
face picon face
> 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_OUTjamesnewtonTakeThisOuTspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2005\04\14@071744 by Gerhard Fiedler

picon face
James Newton, Host wrote:

>> 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...

Also known as CC5X http://www.bknd.com/cc5x/features.shtml:
"Linker support (MPLINK), interfaces with assembly (MPASM) modules"

Gerhard

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...