gnupic: Thread: Best output format for a compiler?

Hello all.

Let's suppose I have a Forth compiler project which targets PIC
microcontrollers (incidentally, this is true: http://mary.pepix.net/);

Let's suppose I have the necessary time to work again in the project (this
is currently not very true, but that may change);

Let's suppose that one of the main concerns is not reinventing the wheel
(although it's more than likey that I will);

Let's suppose that integration with current tools is a bonus;

Let's finally suppose the current output format is .hex files (through
stdout).

All that said, now it comes the big prize question:

Which is seen as a more convenient output format for such a compiler in the
current/future toolchain set?

Rationale:

 - .hex files allow for easy integration with device programmers, but
disallows making libraries (currently I use this for internal optimization
reasons)

 - .obj files (if they exist in our current toolchain set) allow making
libraries and sharing code, though they require a linker for converting into
.hex (maybe this would not be all too hard, if the format exists and is
properly documented)

 - .asm files require an external assembler, easing the debugging and
creating libraries (if .obj linking is supported)

So, the real meaning of the question is not "which is the ideal output
format if I have to choose one", as the answer would be easily .asm; but
"which is the more practical format for now and the near future". Several
formats are acceptable, as the proper rationale is given. This is more a
question of "what must be done before and waht after".

The compiler takes Forth as source, so I don't know it integration with C
routines makes sense, but with assembler ones it may well be. I must note
the, lacking time issues aside, the source code is a moving target, as I may
end with something like a wild crossing between "classic" Forth and
colorForth, or something in the spirit. After all, we are looking for a tool
for microcontrollers, not for programming the next DVD interface (for now,
that is... :)

That's all. Thanks in advance for your comments.

Regards.

-- 
Francisco Rodrigo Escobedo Robles - ####@####.####
Pepix.Net: no lo imagines, vivelo - http://Pepix.Net/
Este mensaje expresa unicamente mi opinion en este momento

<IMHO>
Forth is extensibe, so ... extend it to do everything ...

	' my_app_word " myapp.hex" hex_dump
	' my_app_word " myapp.obj" obj_dump
	' my_app_word " myapp.4th" src_dump
	' my_app_word " myapp.asm" asm_dump

Write 'em in order of importance to you, and omit the ones you don't need
(leave as exercise for student).  In each case, the dump should continue
along the threaded execution into the library dictionary until all required
words are implemented ... and the object should be vectored to execute the
`my_app_word' word upon loading.
</IMHO>


On Thu, 26 Feb 2004, Francisco Rodrigo Escobedo Robles wrote:

> Date: Thu, 26 Feb 2004 12:56:41 +0100
> From: Francisco Rodrigo Escobedo Robles ####@####.####
> To: ####@####.####
> Subject: Best output format for a compiler?
>
> Hello all.
>
> Let's suppose I have a Forth compiler project which targets PIC
> microcontrollers (incidentally, this is true: http://mary.pepix.net/);
>
> Let's suppose I have the necessary time to work again in the project (this
> is currently not very true, but that may change);
>
> Let's suppose that one of the main concerns is not reinventing the wheel
> (although it's more than likey that I will);
>
> Let's suppose that integration with current tools is a bonus;
>
> Let's finally suppose the current output format is .hex files (through
> stdout).
>
> All that said, now it comes the big prize question:
>
> Which is seen as a more convenient output format for such a compiler in the
> current/future toolchain set?
>
> Rationale:
>
>  - .hex files allow for easy integration with device programmers, but
> disallows making libraries (currently I use this for internal optimization
> reasons)
>
>  - .obj files (if they exist in our current toolchain set) allow making
> libraries and sharing code, though they require a linker for converting into
> .hex (maybe this would not be all too hard, if the format exists and is
> properly documented)
>
>  - .asm files require an external assembler, easing the debugging and
> creating libraries (if .obj linking is supported)
>
> So, the real meaning of the question is not "which is the ideal output
> format if I have to choose one", as the answer would be easily .asm; but
> "which is the more practical format for now and the near future". Several
> formats are acceptable, as the proper rationale is given. This is more a
> question of "what must be done before and waht after".
>
> The compiler takes Forth as source, so I don't know it integration with C
> routines makes sense, but with assembler ones it may well be. I must note
> the, lacking time issues aside, the source code is a moving target, as I may
> end with something like a wild crossing between "classic" Forth and
> colorForth, or something in the spirit. After all, we are looking for a tool
> for microcontrollers, not for programming the next DVD interface (for now,
> that is... :)
>
> That's all. Thanks in advance for your comments.
>
> Regards.
>
>

On Thu, 26 Feb 2004, Francisco Rodrigo Escobedo Robles wrote:

<snip>

> Which is seen as a more convenient output format for such a compiler in the
> current/future toolchain set?

Well, Let's suppose that someone else wishes to use this Forth tool 
(definitely true);

Let's suppose that they use the other gnupic tools (probably true);

Then it's safe to conclude that they'll be comfortable with an output 
that's compatible with the other tools. So far, the high level compilers 
that I'm familiar with all produce .asm output.

Scott

>>>>> "Francisco" == Francisco Rodrigo Escobedo Robles ####@####.#### writes:

Francisco> Let's suppose I have a Forth compiler project
Francisco> which targets PIC microcontrollers (incidentally, this is
Francisco> true: http://mary.pepix.net/);

Don't you want to work on PicForth instead? :)
(http://www.rfc1149.net/devel/picforth)

Francisco> The compiler takes Forth as source, so I don't know it
Francisco> integration with C routines makes sense, but with assembler
Francisco> ones it may well be. I must note the, lacking time issues
Francisco> aside, the source code is a moving target, as I may end
Francisco> with something like a wild crossing between "classic" Forth
Francisco> and colorForth, or something in the spirit. After all, we
Francisco> are looking for a tool for microcontrollers, not for
Francisco> programming the next DVD interface (for now, that is... :)

You can also do assembly directly in Forth. Or, better, if you want to
interface with an outside module, you can import this module memory
map in your Forth compiler and define Forth words that will output a
call to those assembly words.

I asked myself the same questions when I wrote PicForth. I used it a
lot and never had to interface with external module. As you write, we
do program microcontrollers; it means that there is no huge library to
interface with.

Also, leaving the Forth system implies saving and restoring the stack
and/or W, FSR, etc. You cannot carelessly link with everything and
suppose that everything will work well, as for example an external
routine will probably neither restore W nor FSR.

  Sam
-- 
Samuel Tardieu -- ####@####.#### -- http://www.rfc1149.net/sam

Cool, Mary has woken and PicForth is also active.
I'm going to have to review them both; for my next project.

Keep up the good work.  As for my opinion, I'm prefer semantics like
this;

processor 16f84
: blink portb@ 1 xor portb! ;
: my-application begin blink 100 mS false until ;
program-tait my-application

I'm quite happy to reimplement library code some other way.
And I'd like my Forth to accept assembler mnemonics!

(Of course, this doesn't seem to build on tools ...)

-- 
James Cameron    ####@####.####     http://quozl.netrek.org/

Hello.

Decía Scott Dattalo ####@####.#### el Thu, 26 Feb 2004 08:48:59 -0800
(PST):

> On Thu, 26 Feb 2004, Francisco Rodrigo Escobedo Robles wrote:
> 
> > Which is seen as a more convenient output format for such a compiler in
> > the current/future toolchain set?
> 
> Well, Let's suppose that someone else wishes to use this Forth tool 
> (definitely true);

Well, that was an axiom of mine, not necessarily of anybody else; but it's
good that somebody thought of it :)

> Let's suppose that they use the other gnupic tools (probably true);

That was my assumption.

> Then it's safe to conclude that they'll be comfortable with an output 
> that's compatible with the other tools. So far, the high level compilers 
> that I'm familiar with all produce .asm output.

That's the angle I lacked of. Thanks.

Regards.

-- 
Francisco Rodrigo Escobedo Robles - ####@####.####
Pepix.Net: no lo imagines, vivelo - http://Pepix.Net/
Este mensaje expresa unicamente mi opinion en este momento

Hello.

Decía Samuel Tardieu ####@####.#### el Thu, 26 Feb 2004 18:12:55 +0100:

> >>>>> "Francisco" == Francisco Rodrigo Escobedo Robles ####@####.####
> >writes:
> 
> Francisco> Let's suppose I have a Forth compiler project
> Francisco> which targets PIC microcontrollers (incidentally, this is
> Francisco> true: http://mary.pepix.net/);
> 
> Don't you want to work on PicForth instead? :)
> (http://www.rfc1149.net/devel/picforth)

Well... not a bad idea... but considering I already know my compiler better
than yours (not to mention Mary was there before :) ...

This is not to say there won't be any kind of collaboration. Let me get
steam again with my project, and I'll see what can be done.

> You can also do assembly directly in Forth.

I already do this.

> Or, better, if you want to
> interface with an outside module, you can import this module memory
> map in your Forth compiler and define Forth words that will output a
> call to those assembly words.

I currently don't do this, but it's an interesting approach.

> I asked myself the same questions when I wrote PicForth. I used it a
> lot and never had to interface with external module. As you write, we
> do program microcontrollers; it means that there is no huge library to
> interface with.

I was thinking of existing routines for some complex operation, as long
mathematics, peripheral emulation (serial ports or even USB), or so.

> Also, leaving the Forth system implies saving and restoring the stack
> and/or W, FSR, etc. You cannot carelessly link with everything and
> suppose that everything will work well, as for example an external
> routine will probably neither restore W nor FSR.

Very true. In that case, there would have to be some kind of interface
between languages (à la "extern" in C) in order to guarantee the proper
context respect. Not an easy one.

Regards.

-- 
Francisco Rodrigo Escobedo Robles - ####@####.####
Pepix.Net: no lo imagines, vivelo - http://Pepix.Net/
Este mensaje expresa unicamente mi opinion en este momento