[Coco] Re: gcc-coco revisited

[Theodore A. Evans]

On 11/01/03, John E. Malmberg wrote:

> Theodore A. Evans wrote:
>> On 10/31/03, John E. Malmberg wrote:
>> 
>>> Also for the education of those that are used to traditional compilers,
>>> GCC is a bit different.
>>> 
>>> GCC is a shell that calls/chains the other programs in sequence to
>>> produce the expected results. The preprocessor program is typically
>>> separate from the complier, followed by an optimizer program, followed
>>> by the assember program, and finally a linker program.
>> 
>> That *is* the way that traditional C compilers work.  Microware C
>> works that way as does pretty much every C compiler I have ever used.
> 
> On almost every platform that I have programed C regularly on, there is 
> one complier image that takes the source module and produces an object 
> module.  I can usually request the various intermediate outputs.

The stock cc under SunOS, Solaris, IRIX, Unicos, and HP-UX all work
this way.  Of course for NextSTEP and Darwin the stock compilers work
this way, but they are derived from gcc.  vbcc works this way.  On the
Amiga StormC LatticeC, and SAS/C all work this way.  Borland C worked
this way the last time I used it.

> I have a few commercial C complilers for Microsoft Windows, and they 
> work that way.

I believe that I have *never* used a C compiler under Windows.

> Of course smaller microprocessor systems tend to chain programs because 
> of memory constraints.

The only influence on Microware C that I know of that I would
attribute to the small systems model is that the compiler (the stage
between the preprocessor and optimizer) is divided in two parts.  It
is some times useful to have a copy of the intermediate result between
the states.  Obviously this is not really a problem on a monolithic C
compiler, but they have traditionally been written in the seperate
parts (the original c compiler worked this way).  Obviously the
prelinker ".o" object files are usedful to have around, especially
during program development.  Sometimes the assembly language files are
nice when you wish to hand tun a section of code, though admittedly
the #ASM pragma is useful for this, and keeps the changes in the
source file.

-- 
"Shocking.  Positively shocking." - 007 (Sean Connery - Goldfinger)
Theodore (Alex) Evans            | alxevans at concentric.net
94-1071 Kepakepa St. Unit #C-1   | http://www.concentric.net/~alxevans
Waipahu, HI 96797                | ICQ 78089262
x                                | (808) 676-0123         2B v ~2B = ?