🚀 go-pugleaf

In article 2033 of comp.sys.amiga.tech, andrew@teslab.lab.OZ (Andrew Phillips) said:

>Over the years I have been intrigued by the code generated by
>different C compilers, and have been comparing Lattice C code with
>Aztec C.  From the first it always seemed that Lattice performed more
>optimizations but that Aztec did better simply because of better code
>generation.  Nowadays, they seem to be much closer, producing
>reasonable code with simple optimizations - but there is a lot of
>room for improvement.

Hello everybody,

My name is Hans Dolfing. I am Computer Science student and currently
graduating. Of course I do own a AMIGA. When I read the former article,
some thoughs an ideas came up which may be interesting for everybody.

Although the C-compilers of Lattice 5.05 and Manx 5.0 work fine, they can
definitely be improved. Maybe, some people on the net are aware of
Borland Turbo-C 2.0 for the Atari ST. If not, you should take a look at it.
It is simply the best C-compiler I have ever seen. Comparing this compiler to
Lattice (now SAS) and Manx for the amiga, you can see that Turbo-C beats
them on almost everything.

Turbo-C is
 - An integrated package which works fine.
 - It compiles 4 times faster than Lattice and Manx (4000 lines/min).
 - The produced code is better. Especially the register allocation
   strategy is exciting.
 - The library routines are good! Just look at the code of 'memcpy'.

Why isn't there a firm that makes such a compiler for the Amiga?

Maybe, SAS and Manx should think about the following proposals:

- The user-interface (which user-interface?) can be improved. Options
  should be enabled/diabled by clicking on them, just like it is done in
  Turbo-C++/PC.
- I like the project files of Turbo-C/ST and Turbo-C++/PC. Maybe, this
  can be implemented too.
- Compiler and linker should be integrated in a package of around 200/300K
  size. The editor can possibly be integrated using ARexx so that a user
  can decide which editor to use. LSE goes a bit in this direction
  but since  I like to use Cygnus Ed 2.0, this is a problem.
- Why did the size of Manx Aztec increase with 70K to 150K when going
  from version 3.6 to 5.0? This seems an indication that the compiler
  code is growing too large (like the Apple Finder 7.0!). So, please
  reduce the compiler size of lc1, lc2 and cc.
- The compiling process can be done faster (see Turbo-C/ST 2.0).
- The libraries of Lattice and Manx should be reworked. Why do we need
  different library for register and stack variables/arguments. Can't the
  compiler keep track of this? The same is true for 16 and 32 bit
  integers and small and large data/code models. Can't the compiler
  keep some marks which are finally written in the generated .o file so
  that the linker knows which size/model to use? Summarizing, it seems
  to me that at least 6 libraries are superflous!
- Why not putting all variables and arguments in registers? If
  stack args are really needed (eg varargs), we can use __stdargs or
  something comparable. Please use always a small data model. If a table
  becomes too large, the compiler should notice this and change the
  adressing of this (and only this) table to a large model.
- Last but not least, the library routines should be as fast as possible.
  Now, I have sometimes to bother if the used library routine is fast
  enough (memcpy).

P.S. I'am not trying to break down the compilers of SAS and Manx. I'am
  just wondering why there are compilers on other machines (Turbo-C 2.0/ST
  and Turbo-C++/PC) which have a really good user interface, work fine
  and produce good code. Therefore, I gave some hints which may help the
 'compiler-builders' to improve their products and to produce even more
  professional software packages (especially user-interfaces which will
  hopefully be improved under OS 2.0) for this wonderful machine named
  AMIGA.

P.S. 2: Maybe it is a nice idea to put together all good ideas/improvements
        on the net and send them to SAS and Manx?

---------------------------
	Greetings, Hans Dolfing (dolfing@cs.utwente.nl)