Small Device C Compiler suite

> These multiple formats should be selectable on the command line. Currently
> the supported formats i can think of are : CDB, OMF,Extended OMF, and
> ieee695 (unlikely).  These formats would be selected using a mutually
> exclusive output selector on the command line. These tags are : --CDB,
> --OMF, --EOMF, --IEEE695.
These are my two euro-cents:

-g cdb / -g omf / -g emof / -g ieee695

I don't know, if 'g' is the best choice, but it's more the structure of the 
arguments I'd like to improve.

Bernhard

Hi Lenny, Bernhard

As it is now, the AOMF file is created from the CDB file.  Therefore the 
CDB file must be created before the AOMF file.  The problem I see is that 
sdcc builds part of the cdb file at compile time adding comments to the 
generate assembly, and later the assembler and linker complete the job.  So 
when I added the AOMF file output to the linker I thought that since the 
CDB and IHX files where required to create it, it didn't make too much 
sense to add another option.

Anyhow, the only available options in the linker are -h, -o, and -t (and 
they look suspiciously like hex, octal, and decimal), but -z is used to ask 
for the cdb output, so it could be used instead of g

-z cdb / -z omf / -z emof / -z ieee695

But since the linker is out of letters already, it may be better to add 
verbose options...

--debug cdb / and so on

(My two loony-cents :)

Jesus

(By the way, I have been trying to build sdcc using debian potato linux, 
but configure gives me an error in line 20.  Something like "error near 
unexpected token `elif'", any ideas of what is happening?)

At 11:40 PM 4/26/03 +0200, you wrote:
> > These multiple formats should be selectable on the command line. Currently
> > the supported formats i can think of are : CDB, OMF,Extended OMF, and
> > ieee695 (unlikely).  These formats would be selected using a mutually
> > exclusive output selector on the command line. These tags are : --CDB,
> > --OMF, --EOMF, --IEEE695.
>These are my two euro-cents:
>
>-g cdb / -g omf / -g emof / -g ieee695
>
>I don't know, if 'g' is the best choice, but it's more the structure of the
>arguments I'd like to improve.
>
>Bernhard
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>sdcc-devel mailing list
>sdcc-devel@...
>https://lists.sourceforge.net/lists/listinfo/sdcc-devel

Jesus,

I had the idea of doing it after the linker because of your implementation.
My idea was to try to not decode the existing CDB to build the selected
format, but rather encode it directly. I know this results in more work, as
the current implementation is not written that way, but i think it would be
cleaner. Fully realizing that i will have to write the encoder, which
shouldnt be that big of a deal.

The Pic Port :
---------------
Scott responded to a question regarding the pic port, and stated that it has
its own object format, and does not use CDB. I had thought to try to make
this work for all the ports. Is there a technical reason why the CDB format
is not used for the PIC ?

Thanks
-Lenny

-----Original Message-----
From: sdcc-devel-admin@...
[mailto:sdcc-devel-admin@... Behalf Of Jesus
Calvino-Fraga
Sent: Sunday, April 27, 2003 2:11 AM
To: sdcc-devel@...
Subject: Re: [sdcc-devel] Debug Output Enhancements : Round 2 <--- Jesus
Read This


Hi Lenny, Bernhard

As it is now, the AOMF file is created from the CDB file.  Therefore the
CDB file must be created before the AOMF file.  The problem I see is that
sdcc builds part of the cdb file at compile time adding comments to the
generate assembly, and later the assembler and linker complete the job.  So
when I added the AOMF file output to the linker I thought that since the
CDB and IHX files where required to create it, it didn't make too much
sense to add another option.

Anyhow, the only available options in the linker are -h, -o, and -t (and
they look suspiciously like hex, octal, and decimal), but -z is used to ask
for the cdb output, so it could be used instead of g

-z cdb / -z omf / -z emof / -z ieee695

But since the linker is out of letters already, it may be better to add
verbose options...

--debug cdb / and so on

(My two loony-cents :)

Jesus

(By the way, I have been trying to build sdcc using debian potato linux,
but configure gives me an error in line 20.  Something like "error near
unexpected token `elif'", any ideas of what is happening?)

At 11:40 PM 4/26/03 +0200, you wrote:
> > These multiple formats should be selectable on the command line.
Currently
> > the supported formats i can think of are : CDB, OMF,Extended OMF, and
> > ieee695 (unlikely).  These formats would be selected using a mutually
> > exclusive output selector on the command line. These tags are : --CDB,
> > --OMF, --EOMF, --IEEE695.
>These are my two euro-cents:
>
>-g cdb / -g omf / -g emof / -g ieee695
>
>I don't know, if 'g' is the best choice, but it's more the structure of the
>arguments I'd like to improve.
>
>Bernhard
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>sdcc-devel mailing list
>sdcc-devel@...
>https://lists.sourceforge.net/lists/listinfo/sdcc-devel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
sdcc-devel mailing list
sdcc-devel@...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel

On Sun, 27 Apr 2003, The Storys wrote:

> Jesus,
> 
> I had the idea of doing it after the linker because of your implementation.
> My idea was to try to not decode the existing CDB to build the selected
> format, but rather encode it directly. I know this results in more work, as
> the current implementation is not written that way, but i think it would be
> cleaner. Fully realizing that i will have to write the encoder, which
> shouldnt be that big of a deal.
> 
> The Pic Port :
> ---------------
> Scott responded to a question regarding the pic port, and stated that it has
> its own object format, and does not use CDB. I had thought to try to make
> this work for all the ports. Is there a technical reason why the CDB format
> is not used for the PIC ?

Yes. At the time I started working on the PIC port, most people used
either MPASM (Microchip's Assembler) or gpasm (the open source equivalent
of Microchip's assembler) for their PIC assembler. (I suspect this is
still true). Since I do all of my development under Linux, I use gpasm.  
Unfortunately, at the time I started the PIC port, their was no PIC linker
that worked with gpasm. Now there is.

Also, I know that almost all new users of PIC's begin with MPLAB. One day 
I hope that SDCC can be integrated into MPLAB the same way commercial 
compilers are today. The only realistic way this will happen is if SDCC 
conforms to Microchip's MPASM. 

The CDB format unfortunately clashes with the MPASM/gpasm syntax. I
suppose we could introduce the CDB format back into the PIC port if we can
insure that it won't clash with gpasm. For example, we can embed the CDB
commands in carefully crafted comments. I already embed gpsim debugger 
commands in SDCC generated assembly comments.


Scott