Yes I would agree , the .exe bloat would be a concern.
If someone wants to take on this project. I have a few
suggestions.
By default SDCC builds the way it is (i.e. with all targets
, target chosen with -m<target name>.
To build for a specific target we use the --target flag
of configure... ie. ./configure --target=<target_name>
just like gcc, in this case the -m option either becomes invalid
or issues a meaningful error message .
Sandeep
-----Original Message-----
From: sdcc-devel-admin@...
[mailto:sdcc-devel-admin@... Behalf Of Dr Russel
Winder
Sent: Monday, March 12, 2001 5:21 AM
To: sdcc-devel@...
Subject: Re: [sdcc-devel]Is a new build structure needed ?
> With the 8051, DS390, Z80, AVR and PIC ports already in process and talk
of the XA51 port and my intention to add the HC05 and HC08 and possibly the
ST7 families to the pot soon, we are starting to see some feature and
options interactions as well as "exe bloat". I understand that this can
currently be done by configuring out particular ports and creating different
directories and naming conventions for the executables etc. But who wants
to do that manually. The people using this "product" are either coming from
a Win/DOS environment, where you generally buy a tool set for a particular
processor or they are coming from the Linux side with the experience of gcc
with the various ports available.
My understanding is that termination of production runs of the 68HC08 has
been announced. All the people I know who use this device are now tooling
up to work with other devices.
I agree that there is a problem as more and more ports are introduced -- cf.
creating gcc for all machines and separate systems for each machine. The
former leads to huge executables and the later leads to vast replication.
Some stream of consciousness thoughts on the issues for SDCC:
1. There needs to be different parsers for different processors -- features
appropriate for the 8051 are not appropriate for the z80. This can be
handled by different grammars or choice sections in the code. I suspect the
latter more appropriate for SDCC.
2. There needs to be different libraries. This is really an issue of code
management. I believe this can be handled by careful *.lib file naming and
management. Given a basic code base there need to be separate *.lib files
for each target to show. This avoids replication.
3. There needs to be different header files. This is really an issue of
setting up conditional compilation within a single set of header files.
This is relatively straightforward it just needs doing. We have volunteered
to do an initial pass on this relating to the z80 port. Work on this will
start next week.
Russel.
====================================================================
Dr Russel Winder Chief Technology Officer
OneEighty Software Ltd Tel: +44 20 8263 2329
The Lansdowne Building Fax: +44 20 8263 6314
2 Lansdowne Road R.Winder@...
Croydon, Surrey CR9 2ER, UK http://www.180sw.com
====================================================================
Under the Regulation of Investigatory Powers (RIP) Act 2000 together
with any and all Regulations in force pursuant to the Act One Eighty
Software Ltd reserves the right to monitor any or all incoming or
outgoing communications as provided for under the Act
_______________________________________________
sdcc-devel mailing list
sdcc-devel@...
http://lists.sourceforge.net/lists/listinfo/sdcc-devel
|