Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!bionet!agate!teak.berkeley.edu!nj
From: nj@teak.berkeley.edu (...)
Newsgroups: comp.sys.amiga.tech
Subject: Re: C compilers code generation
Message-ID: <1990Nov12.164804.5490@agate.berkeley.edu>
Date: 12 Nov 90 16:48:04 GMT
References: <1990Nov12.135444.10739@cs.utwente.nl>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: nj@teak.berkeley.edu (...)
Organization: University of California, Berkeley
Lines: 93

[I was originally going to respond to this via email, but it
 bounced.  Hopefully n-million other people won't post followups
 as well.]

I've seen Turbo C on an Itty Bitty Machine, and the integrated
environment is nice.  However, some of your objections have in fact
been addressed to some extent with SAS C 5.10, and (at least according
to what they say in the documentation) will be improved even more in
the next release.

>- 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.

SAS C 5.10 comes with an Intuitionized tool that can set most compiler
options.  The interface has 2.0-style gadgets (even under 1.3--don't
know how they pulled this off; maybe they grabbed the gadtools code
from 2.0 and put it directly in the program) and makes sure everything
fits together right (e.g. if you select registerized parameters, it'll
link with the registerized library, etc.).  It's not perfect yet, but
they acknowledge this in the dox, and promise to improve it in the
future.

>- I like the project files of Turbo-C/ST and Turbo-C++/PC. Maybe, this
>  can be implemented too.

I don't know what project files are, but I assume they're similar to
makefiles, which SAS has.  Granted, makefiles are a bit weird, but since
SAS was partially targeted at people coming from UN*X, it's understandable.

>- Compiler and linker should be integrated in a package of around 200/300K
>  size. 

There's no provision for this yet.

>  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.

Version 5.10 comes with a program that will let you invoke CED instead of
LSE after the compiler finds an error.  I guess the problem with using
other editors is that they may not have the same AREXX commands for
moving to a specific line or whatever.  

>- 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).

Don't know about these two, though the compiler tends to increase in
speed with each release.

>- The libraries of Lattice and Manx should be reworked. 

This is a bit annoying, both in terms of disk space and getting the
command line straight.  Not being a compiler guru I don't know how
easy it would be for them to fix this; if they ever got around to
integrating the compiler and the linker, they might find a solution.
In the interim, the Intuitionized interface to the compiler will keep
track of all the libraries for you.

>- Why not putting all variables and arguments in registers? If
>  stack args are really needed (eg varargs), we can use __stdargs or
>  something comparable. 

This is just a matter of compiling with the -rr option and linking with
the right library.

>  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.

In version 5.10, LC1 defaults to "near" on everything; if it runs out
of room, it starts making things "far".  (I assume this is what you
mean by "small data model".)  Also, blink has a SMALLDATA option for
merging all the near data into one hunk.

>- 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).

Don't know about this.  In the interim, of course, you can use the Exec
routine CopyMemQuick().

There are many improvements to be made to SAS C, but I think they're
getting a little better.  I do hope they add more to their
Intuitionized interface, and integrate it with the makefiles (right
now you can make it so it only compiles files that have been recently
changed, but it won't take dependencies into account).


nj