[comp.sys.amiga.programmer] C compilers

borkoles@cs.qmw.ac.uk (Borkoles; Phd) (01/25/91)

I am writing this on behalf of a friend who has recently gone from st to amiga 
and is trying to break into C programming. What are the best C compilers out 
there for the Amiga, price is, realistically, an issue. Any help appreciated!

cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (04/04/91)

In article <mykes.1332@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>Maybe someone can answer these questions for me:

I can't answer many of your questions, but I have a few comments
and maybe an enlightenment or two.

>Why is the best compiler on the Amiga run the bejeezes slow?  In my
>experience, your development cycle (edit/compile/link/run/debug and
>repeat all the above) is critical to your productivity.

See below...

>fWhy isn't something like LightSpeed 'C' available for the Amiga?  It
>flies and generates awesome code.

Don't know, but I personally perfer SAS/C 5.10a to LightSpeed 4.x
anyways so this does not bother me.  I would like SAS/C to
go at LightSpeed though :-).

>Why hasn't someone made the entire c.lib into a loadable library
>so all programs can share it instead of duplicating these routines
>hundreds of times all over everyone's hard disks?  Why not even
>just printf.library (this alone would save megabytes on my hard disk)?

I think Matt's DICE library routines could be placed into a library,
Matt?  This really is something that should have been done *a* *hell*
*of* a long time ago...

>Why didn't Jez Sans write a 'C' compiler?

Who's Jez Sans?  Never heard of him...

>Why don't 'C' compilers support linkerless usage?
>
>Why don't 'C' compilers know about the routines in the OS without
>#pragmas?  While we're at it, why not all the structures and other
>things from the header files, too?

Have you ever used precompiled headers?  They will make SAS/C (and
I'd bet Aztec) fly.  You can set it up so all the above info
(i.e. #pragmas for all OS routines and all the structures) are in
one neat little file that the compiler loads before compiling your
source.  This can really speed up SAS/C.

>Why don't 'C' compiler c.lib libraries automatically use the Exec
>Task structure's TC_TRAPCODE field to trap 99% of the gurus that
>happen and force programs to exit gracefully?  Maybe the question
>is why don't 'C' programmers do it all the time?

OK, here is another great point!  This too should have been done
a long time ago... I guess we could also ask why don't 'asm' 
programmers do it all the time? :-)
I will make on side point, how come *all* programs on the Amiga
don't do something logical upon seeing the SIGBREAKF_CTRL_C flag
set?  Every program I write can be halted with a `break <CLI>'
or more generally, Signal (TaskAddr, SIGBREAKF_CTRL_C).

>Why do 'C' programmers ask me whether I use:
>	MULU	#17,d0
>instead of:
>	move.l	d0,d1
>	lsl.l	#4,d0
>	add.l	d1,d0
>when it is basic programming normally done by assembler language
>programmers (one of the oldest tricks in the book)?

I would never ask such a dumb question...

>Come on people, no flames for this, these are serious questions.
>--
>****************************************************
>* I want games that look like Shadow of the Beast  *
>* but play like Leisure Suit Larry.                *
>****************************************************
Me too...

Loren J. Rittle
-- 
``NewTek stated that the Toaster  *would*  *not*  be made to directly support
  the Mac, at this point Sculley stormed out of the booth...'' --- A scene at
  the recent MacExpo.  Gee, you wouldn't think that an Apple Exec would be so
  worried about one little Amiga device... Loren J. Rittle  l-rittle@uiuc.edu

ronny@minnie.cs.su.OZ.AU (Ronald Cook) (04/04/91)

>>Why hasn't someone made the entire c.lib into a loadable library
>>so all programs can share it instead of duplicating these routines
>>hundreds of times all over everyone's hard disks?  Why not even
>>just printf.library (this alone would save megabytes on my hard disk)?
>
>I think Matt's DICE library routines could be placed into a library,
>Matt?  This really is something that should have been done *a* *hell*
>*of* a long time ago...

NO! NO! PLEASE, NO!

Not all Amiga users have hard drives. In fact, a majority are limited to
floppies. The recent tendency of Amiga programmers to stick everything
into a shared library is disquieting (for me, at least) because most
people, when faced with adding yet another large file to their boot
disk, will not do so unless the program is one which they DESPERATELY
need. Every 10K library which you ask me to put on my boot disk chews up
better than 1% of a space which needs to hold -

1) Most of the commands which you often use.
2) Libraries and devices
3) Fonts (I get around this with a "assign FONTS: remove in my s-seq,
but most aren't so lucky).
4) drivers and other stuff (l: , s:, etc)

I have several good programs which I don't use because I don't have the
space for their shared libraries on my boot disk. There are ways of
getting around this sort of thing, but they are not really suitable for
the novice user. Most such libraries, also, are only iused by a relative
handful of programs.

Ideally, hard disk users could have a version which uses a shared
library, and floppy users could have a version which uses a compile-time
version. But this almost doubles the size of a distribution.

I'm not exactly rich, but I'll be getting a hard drive soon, and getting
into some serious programming. But any programs that I write will NOT
make it compulsory for ANY files to sit on the boot disk.

		....Ronny (Cook)

dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/05/91)

In article <1991Apr3.233053.7051@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes:
>In article <mykes.1332@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
>>...
>
>>Why hasn't someone made the entire c.lib into a loadable library
>>so all programs can share it instead of duplicating these routines
>>hundreds of times all over everyone's hard disks?  Why not even
>>just printf.library (this alone would save megabytes on my hard disk)?
>
>I think Matt's DICE library routines could be placed into a library,
>Matt?	This really is something that should have been done *a* *hell*
>*of* a long time ago...

    All the standalone routines can, and, in fact, pfmt() (used by
    [v][s][f]printf()) is standalone, as well as things like strcpy(),
    movmem(), etc...

    Under 2.0, many of the routines that would otherwise not be easily
    placed in a shared library have direct OS equivalents now.

    The reason you don't see much in the way of common code is that most
    programmers generally want to provide standalone executables.

    You can't put everything into a shared library, though... something
    like atexit() would be difficult.  The actual overhead of c.lib isn't
    all that bad.

>>Why didn't Jez Sans write a 'C' compiler?
>
>Who's Jez Sans?  Never heard of him...

    General good guy... never wrote a C compiler because he never had the
    desire to, for the same reason I have never written, say, a postscript
    interpreter.  What a dumb question.

>>Why don't 'C' compilers support linkerless usage?

    Because a C program is generally made up of several modules, not
    to mention link libraries... this is another stupid question.
    Besides, you can generate absolute-relocated images just fine,
    it's called ROMABLE (in the DICE dist) and converts an executable
    into an absolute relocated image.

    Not EVEN to mention that the *ONLY* people who care about linkerless
    usage in the context you are talking about are, game programmers.  The
    only time I use absolute relocated images is when I'm writing ROMd
    code for custom 68000 boards.

>>Why don't 'C' compilers know about the routines in the OS without
>>#pragmas?  While we're at it, why not all the structures and other
>>things from the header files, too?

    Huh?

>>Why do 'C' programmers ask me whether I use:
>>	MULU	#17,d0
>>instead of:
>>	move.l	d0,d1
>>	lsl.l	#4,d0
>>	add.l	d1,d0
>>when it is basic programming normally done by assembler language
>>programmers (one of the oldest tricks in the book)?
>
>I would never ask such a dumb question...

    Neither would I.  I think Mike (Schwartz) missed the point of that
    particular posting... the point being that many of todays C compilers
    will do those kind of optimizations automatically so the programmer
    doesn't have to think about it.  In assembly, you have to take a
    certain amount of time to plop them down.  Of course, the MULU example
    above is intuitivly obvious... A compiler like GCC or SAS/C will do
    optimizations such as strength reduction and loop unrolling on
    arbitrarily complex subroutines, something that would take a LOT longer
    to optimize by hand, which is the point of the observation.

>>Come on people, no flames for this, these are serious questions.
>>--
>>****************************************************
>>* I want games that look like Shadow of the Beast  *
>>* but play like Leisure Suit Larry.		     *
>>****************************************************
>Me too...
>
>Loren J. Rittle

			-Matt

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

rhialto@cs.kun.nl (Olaf'Rhialto'Seibert) (04/07/91)

In article <2259@cluster.cs.su.oz.au> ronny@minnie.cs.su.OZ.AU (Ronald Cook) writes:
>>>Why hasn't someone made the entire c.lib into a loadable library
>>>so all programs can share it instead of duplicating these routines
>>>hundreds of times all over everyone's hard disks?  Why not even
>>>just printf.library (this alone would save megabytes on my hard disk)?

>NO! NO! PLEASE, NO!
[...]
>I have several good programs which I don't use because I don't have the
>space for their shared libraries on my boot disk. 

But libraries, devices and fonts don't really have to live in LIBS:,
DEVS: and FONTS:, if they are only used in a single program. It is
possible to use OpenLibrary("VOLUME NAME:path/some.library", ...),
OpenDevice("VOLUME NAME:path/some.device", ...), and 
OpenDiskFont("VOLUME NAME:path/some.font", ...).

The requested resource is then first looked for in memory (with volume
and path removed of course), then in LIBS: DEVS: or FONTS:, and if that
also fails finally in the exact location specified. This makes it possible
to either leave it on the distribution floppy (for floppy users) or put
it on your boot disk (for harddisk users). For example, NetHack does
this with its graphics font, and WP with its overlays (which seem to be
handled like libraries).

>		....Ronny (Cook)

--
Olaf 'Rhialto' Seibert                               rhialto@cs.kun.nl
How can you be so stupid if you're identical to me? -Robert Silverberg

uzun@pnet01.cts.com (Roger Uzun) (04/07/91)

[]
Just out of curiosity, I checked the  x *= 17; statement with
SAS/C 5.10a, basically it does do an lsl #4 and an add #1, as
long as the argument is not a short when compiled without the -w
option.  If the argument is a short and 32 bit ints are the default,
the compiler uses a mul #$11 rather than the lsl, add.  In all other
cases it seems to do an lsl, add sequence.

I guess compilers are getting smarter.

-Roger

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.com