[Coco] Compiler info from an offline conversation...

[James Jones]

secure at ytunnelpro.com wrote:

>Small-C: There are several versions of this floating around including
>some of the first run updates and modifications. Keep in mind that
>Small-C supports only a subset of C and most versions don't support
>things such as multiple dereferencing of pointers, bitfields, and
>exhibits some problems with switch/case statements. Overall Small-C is a
>decent place to start since it's small, widely available, easy to
>follow, and can be modified quite easily even if the code it generates
>isn't exactly efficient. Most versions of Small-C do not support long
>(32bit int) or floats.
>
>  
>
I'm not sure that Small-C even supports structures, much less 32-bit 
integers or float/double.

>Introl-C: This is a commercial compiler and I'm not sure if it's even
>available anymore. This one is somewhat pricy. I don't know much about
>Introl-C as I've never seen o used it.
>
>  
>
Well... http://www.micro.uqam.ca/Ressource/introl/ is interesting; in 
particular, note:


      Introl-CODE® Version 4.00

------------------------------------------------------------------------

CODE, the COntroller Development Environment, is an integrated tool that 
can help you develop programs for embedded systems using Motorola 
mocrocontrollers.

This manual describes both the commercial and non-commercial versions of 
CODE: they are identical. The demo version of code is also identical 
except that the various programs have limitations built in. For example, 
the size of programs that may be compiled, assembled, and linked is limited.

------------------------------

The "intro" reachable from the above URL has a link to www.introl.com, 
but that doesn't resolve, so Introl may no longer be around. Rummaging 
around further, it looks like this is on a site of a Francophone 
Canadian educational institution, and they may have, or have had, 
permission to use
the Introl package as such.

>BCC: This is a C compiler created by Bruce Evans and is widely available
>on the Net. It's also included in several Linux distros and can be
>found in most GNU or Linux archive. It generates fairly decent code
>although it seems to lack good register tracking/allocation, does not
>include a lot of internal optimizations, and has only a handful of bugs.
>This is the compiler that I used to do a proof of concept port of the
>Micro Emacs distro on my site. After creating compatible screen and
>keyboard 'drivers' along with a minimal standard C library
>implementation I was able to get Micro Emacs up and running on the CoCo
>III.
>  
>
Interesting... the problem with most 6809 compilers that don't target 
OS-9 as such is that they probably do things like absolute addressing 
that render them unsuitable for OS-9, though you may be able to  sleaze 
by on that under Level Two, thanks to memory mapping. (I think that's 
how Chris Burke managed to get DECB to run under OS-9 on the CoCo 3.)

>Micro-C: This is a commercial compiler from Dunfield Development systems.
>It generates fairly decent code, includes a slew of tools, and uses a
>common code base used in all the 8 bit compilers DDS provides. Prices
>range from $100 to $200 which if you consider the original Level II
>development system (including the C compiler) ran about $79 or $89 back
>in the 80's. Source is not included with a purchase. I've played
>around with the 8088 version and 6809 version of the compiler and it
>seems to work very well but does not include some features in the C
>language.
>
>GCC: There is currently an effort to add a 6809 code generator to GCC.
>Right now is looks pretty stable and is an ongoing project. The only
>problem eight now is that no distro is available yet meaning you will
>need to download GCC, add the 6809 code generator, and compile it. I'm
>currently working on getting a Win32 distro put together using Cygwin
>though but I'm not sure when it'sll be done. The use of GCC has
>several advantages as you have access to front ends for Fortran, C++,
>Objective-C, Pascal, Modula, and several others like Cobol. If you have
>the time and patience needed to download and compile GCC as it requires
>lots of disk space and can take a while to compile on older systems. GCC
>Is however one of the more desirable compilers as it supports more than
>just C.
>  
>
The other thing is that not only does gcc support C89, it supports some 
features of C9X.

>SDCC: The Small Device C compiler was designed to specifically target
>8bit cpu's with limited registers. Creating a code generator for this
>compiler is somewhat involved and very time consuming as it appears a
>good amount of code must be implemented to compile for the target
>machine. SDCC is a great compiler though and is updated frequently. I
>only mention this for completness and don't think I would recomment
>using SDCC if you're going to write a significant amout of code for
>code generation.
>
>Tiny-C: This compiler only targets x86 but could be modified to generate
>6809 assembler. It's a farily decent compiler but requires you write
>about 60,000 lines of code for a code generator. This compiler also is
>not designed as a cross compiler but it's a good candidate to be one.
>
>LCC: This is a free ANSI-C compiler created by Chris Fraser and David
>Hansen. When I first started looking into Compilers for the CoCo some
>years back I ran into this little gem. The compiler was described in
>"lcc, a Retargetable Compiler for C" a book written by the LCC
>Authors. The book is definitely interesting reading. The compiler itself
>is implemented in such a way that multiple CPU/Machine targets can be
>compiled in withouth hassle allowing the same compiler binary to be used
>to compile for multiple targets. The entire code generation part of the
>compiler is stored in a "machine description" file and parsed into a C
>source file. Other than GCC this is up there in the top three compilers
>that have great potential to be used as a 6809 C compiler.
>  
>
Someone whose name I'll remember at about 3:00 tomorrow morning--ha! 
Google is your friend; Chet Simpson--was trying to target the 6809 with 
lcc, but I think that it made some assumptions that didn't really make 
it suitable for targeting "8-bit" processors.

(Looks down at the signature...) Oh, hi, Chet! :)

>BDS: I know very little about this compiler other than the source code is
>available and it generates 8080 assembler. Because it targets 8bit
>cpu's it's something to at least investigage.
>
>Watcom-C: I only mention this because the source code is freely available
>even though it currently generates x86 code. It could probably be
>modified to generate 6809 assembler but i don't think the time
>investment would yield comparable results.
>
>Microware C compiler/Flex Compiler: These compilers are generally
>considered the defacto standard for the systems they run on. The reason
>I mention both compilers at the same time is that the Flex C compiler
>looks VERY similar to the Microware compiler. Both operate in two passes
>(cpass1, cpass2) where the first pass creates intermedial code (ICODE)
>extremely similar to Microwares. As I understand it though Microware was
>able to merge cpass1 and cpass2 into a single application but it was
>never released. The C code for the Flex compiler is available in the
>flex archives. If you need just the compiler let me know and I'll dig
>it up for you.
>  
>
The cpass1/cpass2 split was for Level One systems. For Level Two, there 
was a compiler sold with a single "c.comp" program run by the compiler 
executive "cc". I know, I ran it on the Smoke Signal Broadcasting 
Chieftain owned by a guy who ran an analytical laboratory that I worked 
for in the early to mid-1980s. You'd probably have to ask someone who 
worked at Tandy at the time why they didn't think that version of the 
compiler worth offering for the CoCo 3.

>The interesting thing about these two compilers is that *IF* the Flex
>compiler is a decendant of the Microware compiler (or predecessor) it
>should be able to compile itself AND run on the CoCo III with no
>modification. If you need a CoCo hosted compiler THIS is the first and
>probably only compiler you should look at as it's the only one that has
>the potetial to run on the CoCo *AND* generate decent code while
>allowing updates, enhancements, and fixes to any bugs that may be found.
>  
>
I think the Flex and Microware compilers have a common ancestor.

>Presently there is no 6809 code generation/back end available for LCC
>although there are various implementation which target the 6502 and and
>Z80. If you're thinking about using LCC and creating a 6809 code
>generator/back end for LCC forget it. LCC was designed for CPU's with
>multiple accumulator and multiple index registers. Because of this the
>front end code tree generator will vomit during register allocation. The
>reason for this is the register allocator (in the front end) gets caught
>in a loop when processing large or slightly complex expressions because
>the "spills" the contents of the accumulator (ACCD) and loads it with
>the new result of another code tree in the expression. The only way
>around this is to implement a custom register allocator to deal with the
>lack of additional registers. You could of course create a considerable
>number of pseudo register operations but that's a SIGNIFICANT
>undertaking and is not guaranteed to work.
>
>Although the back end (described in a BURG file and converted to C code)
>can be used to implement some extremely tight optimizations It's has
>several inherent issues. There hope though. When I last looked into
>using LCC for CoCo development I modified one of the non-cpu specific
>code generators (the symbolic target) to emit ITCODE files (Intermediate
>Text Code) reflecting the code tree the compiler generates while
>defining code blocks, etc. This however poses an additional complexity -
>an additional parser/compiler needs to be written to parse and then
>translate the ITCODE into assembler. This also means that you lost a lot
>of the internal optimizations that the BURG implementation provides.
>
>  
>
Acronym expansion for the general public: BURG probably stands for 
Bottom-Up Rewrite Grammar. Bottom-up rewrite systems, formally studied 
by various folks (Pellegri-Llopart--ah, looks like he did his 
dissertation on applications to code generation),  are usable for 
compiler code generators. BURG and IBURG are packages written by some 
other folks; I forget their names, apart from Todd Proebsting, whose 
name is kind of memorable. :)) The difference is that BURG does a bunch 
of work at code generator generator time; the result is faster, but you 
can't do some things that the interpretive IBURG allows. (The standard 
example is changing behavior based on things like the particular value 
of a constant, e.g. noticing in a 68xxx back end that you can use a 
moveq or addq because you're moving or adding a constant that has a 
paricular value.)

>Again, don't fret as the ITCODE parser allows for additional
>optimizations desperately needed for targeting 8bit CPU's (such as full
>register tracking). Since the ITCODE parser is a seperate entity things
>such as code generation and register allocation you do gain some
>flexibility.
>
>The method of using ITCODE may be time consuming but can yield extremely
>well generated. Once I find the source for my ITCODE parser I'll send
>it out to you.
>
>
>Here are some other notes about compilers:
>
>Most ANSI C compilers generate a certain amount of code that doesn't
>make sense when targeting 8bit cpu's. This is generally a preamble
>which promotes basic types to be aligned on a sepcific boundry. You
>might see code like this:
>
>void function(int param)
>{
>}
>
>compiles to:
>
>   ldd param,s
>   std param,s
>
>This is to ensure things like the following are taken into account:
>
>void function(char param)
>{
>}
>
>compiles to:
>
>    ldb param+1,s
>    sex
>    std param,s
>
>This makes sure that the argument is promoted to signed (or unsigned)
>type of size(int) to accomodate promotion of signed/unsigned types.
>
>
>  
>
For parameter passing, you can't really avoid doing that. (If the call 
is inlined, it's not really parameter passing any more, right?)  That 
said, what you _can_ do is avoid a lot of "gratuitous SEX" when you 
evaluate expressions, e.g. given

    char    c;
    int      i, j;

 you can, assuming integer arithmetic doesn't trap on overflow, turn

    c = i + j;

into

    c = (char) i + (char) j;

and do the addition without widening because of what you know about 
what's going to be done with the result. (In the C standard, that's 
called taking advantage of the "as if" rule, i.e. as long as the 
observable results are the same, you don't have to strictly conform to 
the operations the standard describes as being done when they try to say 
what various expressions or statements mean.) Microware's 6809 compiler 
and the earlier  versions of the 68000 compiler didn't do that, but I 
added that to the 68000 compiler, and of course it made its way into 
Ultra C.

>Peephole optimizers:
>
>Prepare to use a peephole optimizer no matter which compiler you go with.
>No matter how hard you tweak the code generation there will almost
>always be a need for a peephole optimizer to remove or write code
>blocks. This is also beneficial is that some optimizations might be
>implemented easier or quicker in a peephole optimizer. Your code
>generator might end up doing something like:
>
>    a = c;
>    b = c;
>
>compiles to:
>
>    ldd 0,s
>    std 2,s
>    ldd 0,s
>    std 4,s
>
>which can be optimized to:
>
>    ldd 0,s
>    std 2,s
>    std 4,s
>
>
>Although redundent loads are often handled by the code generator it's
>might easier to implement in a peephole opimizer. In other cases it can
>be crucial to handle optimizations within the code generator is it can
>implement register usage across expressions including common
>subexpression elimination. Compilers like LCC handle constant folding (a
>= 2 + 5; compiles to a = 7;)
>
>Also keep in mind that if you are targeting RS-DOS there is no standard
>runtime or crt0 lib although the GCC 6809 project does include one which
>could easily be used with other compilers.
>
>
>
>That's all for now....more to come later.
>
>...Chet...
>
>  
>