DICE vs GCC

DICE vs GCC

Post by tjha.. » Wed, 03 Apr 1991 23:20:21



This may not be the correct newsgroups to post  this,  so  if  it
isn't, please just ignore it.

What are the merits of Matt Dillon's DICE over the  current  ver-
sion  of  GNU  C  for AmigaDOS?  I know about the memory require-
ments, but I want to know from a programmers point of view  which
is  better.  The majority of my experience with C programming has
been under Unix and VMS.  I've used GNU C  running  on  our  Suns
here,  and it seems quite good.  How does the Amiga port compare?
How does DICE compare to GNU C on (Suns or Amigas) ?   Also,  are
there  any plans to port gdb to the Amiga?  I'm used to using dbx
or gdb under Unix, and I miss that sort of thing  when  I'm  pro-
gramming  on  my  Amiga.   I'd  really  prefer to go the route of
shareware or something like GNU C,  but  if  SAS/C  is  really  a
better choice, I'll go with it.  Just let me know you opinions on
each option.  Sorry if this seems a little jumbled, the  cat  de-
cided that last night was not the time for me to sleep. Thanks in
advance.

**********************************************************
* Tom Hayko                    * Call The Amiga Showroom *


**********************************************************

QUIT

 
 
 

DICE vs GCC

Post by Matthew Dill » Fri, 05 Apr 1991 03:35:16



>This may not be the correct newsgroups to post  this,       so  if  it
>isn't, please just ignore it.

>What are the merits of Matt Dillon's DICE over the  current  ver-
>sion  of  GNU       C  for AmigaDOS?  I know about the memory require-
>ments, but I want to know from a programmers point of view  which
>is  better.  The majority of my experience with C programming has
>been under Unix and VMS.  I've used GNU C  running  on  our  Suns
>here,       and it seems quite good.  How does the Amiga port compare?
>How does DICE compare to GNU C on (Suns or Amigas) ?   Also,  are

    GCC will generate better code than DICE (even better code than
    SAS/C and Manx in most cases).

    DICE is a *lot* smaller and much, much faster in terms of
    compilation.

    DICE, like SAS/C and Manx, also has type qualifiers (__chip, __near,
    __far, __aligned, etc...) that are generally a must for any serious
    programming.  I do not believe the GCC port has implemented any of
    these.

>**********************************************************
>* Tom Hayko                 * Call The Amiga Showroom *


>**********************************************************

>QUIT

                                        -Matt

--


    891 Regal Rd.           uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

 
 
 

DICE vs GCC

Post by Colin Ada » Fri, 05 Apr 1991 12:49:20



>This may not be the correct newsgroups to post  this,  so  if  it
>isn't, please just ignore it.

>What are the merits of Matt Dillon's DICE over the  current  ver-
>sion  of  GNU  C  for AmigaDOS?  I know about the memory require-
>ments, but I want to know from a programmers point of view  which
>is  better.  The majority of my experience with C programming has
>been under Unix and VMS.  I've used GNU C  running  on  our  Suns
>here,  and it seems quite good.  How does the Amiga port compare?
>How does DICE compare to GNU C on (Suns or Amigas) ?   Also,  are
>there  any plans to port gdb to the Amiga?  I'm used to using dbx
>or gdb under Unix, and I miss that sort of thing  when  I'm  pro-
>gramming  on  my  Amiga.   I'd  really  prefer to go the route of
>shareware or something like GNU C,  but  if  SAS/C  is  really  a
>better choice, I'll go with it.  Just let me know you opinions on
>each option.  Sorry if this seems a little jumbled, the  cat  de-
>cided that last night was not the time for me to sleep. Thanks in
>advance.

Well it depends on what you are doing.  I am writing a large
program (>20,000 lines code) and tried using several compilers,
GCC, DICE and SAS C.  Well DICE is probably a lot better now,
but the early version I had (non-registered) was unusable
(sorry Matt :-) ), as it would fall to pieces on syntax
errors etc., and GCC was too buggy for any large project.

SAS C is very good, quite stable (Only discovered 2 major
bugs) and generates good code.  If you are doing a BIG project
I'd go with SAS C, but DICE would be good for anything smaller
and GCC if you're really desperate (unless something
dramatic has happenned, like it is now able to produce
Amiga object files etc.).

>**********************************************************
>* Tom Hayko                    * Call The Amiga Showroom *


>**********************************************************

>QUIT

--
Colin Adams                                  
Computer Science Department                     James Cook University

'And on the eight day, God created Manchester'
 
 
 

DICE vs GCC

Post by Tal Lewis Lancast » Sat, 06 Apr 1991 03:02:17




>>This may not be the correct newsgroups to post  this,  so  if  it
>>isn't, please just ignore it.

>>What are the merits of Matt Dillon's DICE over the  current  ver-
>>sion  of  GNU  C  for AmigaDOS?  I know about the memory require-
>>ments, but I want to know from a programmers point of view  which
>>is  better.  The majority of my experience with C programming has
>>been under Unix and VMS.  I've used GNU C  running  on  our  Suns
>>here,  and it seems quite good.  How does the Amiga port compare?
>>How does DICE compare to GNU C on (Suns or Amigas) ?   Also,  are
>>there  any plans to port gdb to the Amiga?  I'm used to using dbx
>>or gdb under Unix, and I miss that sort of thing  when  I'm  pro-
>>gramming  on  my  Amiga.   I'd  really  prefer to go the route of
>>shareware or something like GNU C,  but  if  SAS/C  is  really  a
>>better choice, I'll go with it.  Just let me know you opinions on
>>each option.  Sorry if this seems a little jumbled, the  cat  de-
>>cided that last night was not the time for me to sleep. Thanks in
>>advance.

>Well it depends on what you are doing.  I am writing a large
>program (>20,000 lines code) and tried using several compilers,
>GCC, DICE and SAS C.  Well DICE is probably a lot better now,
>but the early version I had (non-registered) was unusable
>(sorry Matt :-) ), as it would fall to pieces on syntax
>errors etc., and GCC was too buggy for any large project.
>SAS C is very good, quite stable (Only discovered 2 major
>bugs) and generates good code.  If you are doing a BIG project
>I'd go with SAS C, but DICE would be good for anything smaller
>and GCC if you're really desperate (unless something
>dramatic has happenned, like it is now able to produce
>Amiga object files etc.).

What version of gcc did you use?  I wouldn't say gcc is bug free but I have
found it more stable for my project than SAS or Aztec.   And I have been
producing 1.4 M executables with it!  So I wouldn't say gcc can't handle large
projects.  Because I am doing things that just can't be done with SAS or Aztec.
(I think DICE would fit my needs too but I have been too cheep and too busy
to send Matt the 40 bucks for a full version of his compiler).

Have you tried gcc's "-b -c" combination?  This produces Amiga object files.

SAS does have one of the better de*s I have seen.  But its other tools
are geared more for small projects.  For example its make is really stupid
and forces duplication.  Not only are many of its other tools limited my
the OS command length limit many don't accept input files.  Their Cxref
program is one such an example.  What is the purpose of such a program if
you can only cross reference a set of files < 255 characters?  And CPR
can only handle a command line length of ~160.

In defence to SAS, I think may of these problems that I have mentioned will
be fixed in their next release.

>>**********************************************************
>>* Tom Hayko                    * Call The Amiga Showroom *


>>**********************************************************

>>QUIT
>--
>Colin Adams                                  
>Computer Science Department                     James Cook University

>'And on the eight day, God created Manchester'

Tal Lancaster

 
 
 

DICE vs GCC

Post by Colin Ada » Sat, 06 Apr 1991 12:02:28





>>>What are the merits of Matt Dillon's DICE over the  current  ver-
>>>sion  of  GNU  C  for AmigaDOS?  I know about the memory require-
>>>ments, but I want to know from a programmers point of view  which
>>>is  better.  The majority of my experience with C programming has

>>Well it depends on what you are doing.  I am writing a large
>>program (>20,000 lines code) and tried using several compilers,
>>GCC, DICE and SAS C.  Well DICE is probably a lot better now,
>>but the early version I had (non-registered) was unusable
>>(sorry Matt :-) ), as it would fall to pieces on syntax
>>errors etc., and GCC was too buggy for any large project.

>>SAS C is very good, quite stable (Only discovered 2 major
>>bugs) and generates good code.  If you are doing a BIG project
>>I'd go with SAS C, but DICE would be good for anything smaller
>>and GCC if you're really desperate (unless something
>>dramatic has happenned, like it is now able to produce
>>Amiga object files etc.).

>What version of gcc did you use?

A really early one (can't remember the number), it was just after
it was first announced on the net.  It needed heaps of RAM and was
rather slow....

I wouldn't say gcc is bug free but I have

Quote:>found it more stable for my project than SAS or Aztec.   And I have been
>producing 1.4 M executables with it!  So I wouldn't say gcc can't handle large
>projects.

yes, 1.4M executable is bigger than my small 250k exec. but I'm working
to get it smaller not bigger :-)

  Because I am doing things that just can't be done with SAS or Aztec.

Why not?

Quote:>SAS does have one of the better de*s I have seen.  But its other tools
>are geared more for small projects.  For example its make is really stupid
>and forces duplication.

The SAS de* is pretty good. I have found the make utility to be
ok, once you set it up it works fine.

  Not only are many of its other tools limited my

Quote:>the OS command length limit many don't accept input files.  Their Cxref
>program is one such an example.  What is the purpose of such a program if
>you can only cross reference a set of files < 255 characters?  And CPR
>can only handle a command line length of ~160.

Hmmm. Never had to use Cxref or CPR (it takes too long to compile 43+
files with debugging options on to bother), but that sound's pretty
restrictive.

Still SAS is good enough for me.

>Tal Lancaster


--
Colin Adams                                  
Computer Science Department                     James Cook University

'And on the eight day, God created Manchester'
 
 
 

DICE vs GCC

Post by Loren J. Ritt » Sun, 07 Apr 1991 00:34:11



Quote:>Try compiling the GNU regexp code with SAS/C and the -O option. Then
>try with GCC. SAS/C will introduce subtle bugs. Things like the X

It is interesting that you should say this as I used SAS/C to port
GNU egrep (and others) with no problem.  I have never seen these
subtle bugs you talk about.  I used (let me go check the exact options...)
`-v -cw -D__STDC__ -O' and then I ran the regress tests with no
problems occuring.  And I use this version all the time with no
problems.  What version did you have problems with?

As an aside: I recently had the pleasure to beta test (testing period is
now over...) a new patent-free data compressor.  The guy who wrote
it liked to use a lot of macros (esp. to unroll loops, etc.).  He
attached a comment to one of the lines that read:

/* Sheer hell for your optimizer. [grin] */

Because this one particular macro expanded to 53 lines of code with 13
nesting levels...  (And some of those lines contained other macros!)
He claimed that this would break quite a few C
compilers on UNIX boxes and provided a way to cut the unrolling
down to something almost every compiler should be able to handle.

SAS/C could handle the 5 (max) loop unrolling (this may not seem like a big
deal, but the the algorithm is not your (if you had not already guessed :-)
standard 'for(x=0; x<100;x++){do simple math operation}' type loop).
Needless to say this was also,

/* Sheer hell for your preprocessor. [grin]  ljr, ``Not anymore!'' :-) */
[Comment I later added...]

and caused SAS/C to a have a problem, because it did not like the long
line length (see that macro (and all the others it contained) were really
one huge line and although the macro expansion buffer size can be set with
-z, I have not found a way to get around the line length limit).
After expanding the outer macro expansion by hand and splitting the
code onto 53 lines, SAS/C took the code with no problem.  It took ~30
minutes to compile with -O on my '030 machine, but the executable was twice
as fast as what (not a slam in any way) DICE produced in ~30 seconds!
[Matt: if you want to see some code that DICE does not fair well
on as compared to SAS/C, I can mail you the source.]

Disclaimer: This was version 2.06 (Freely Redistributable release)
of DICE and I may well not given 'good' options to dcc...
Disclaimer2: This was version v5.10A of SAS/C and I know what I'm
doing with this compiler... :-)
Disclaimer3: Full 32-bit addressing was used with both compilers
as this compression code burns memory.

In sum, both DICE and SAS/C were able to handle the max loop unrolling
that the author provided for.  A+ marks (IMHO).

Quote:>window system  sources hose up SAS/C, but GCC will compile them fine.

You may have hit the macro expansion problem, what are the some
of the symptoms?  When SAS/C failed on the macro expansion, I would
get weird error messages, but the compiler never crashed, etc...
Once I split lines up, everything was OK.

Quote:>Even the pd version of DICE will handle some legal constructs that SAS/C
>won't. But SAS/C is a pretty good compiler for the Amiga, especially
>considering the access to the system that it gives you.

>Also, SAS/C seems to be somewhat weak on several of its floating point
>formats. Some of the formats seem to give screwey results. It's hard to
>find out why (see below).

Humm, I've never had a problem with the floating point formats, but then
again I always use -f8.  And I don't work with many programs that
use floating point.



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

 
 
 

DICE vs GCC

Post by Rev. Ben A. Mesand » Fri, 05 Apr 1991 19:48:44




>> Because I am doing things that just can't be done with SAS or Aztec.

>Why not?

Try compiling the GNU regexp code with SAS/C and the -O option. Then
try with GCC. SAS/C will introduce subtle bugs. Things like the X
window system  sources hose up SAS/C, but GCC will compile them fine.
Even the pd version of DICE will handle some legal constructs that SAS/C
won't. But SAS/C is a pretty good compiler for the Amiga, especially
considering the access to the system that it gives you.

Also, SAS/C seems to be somewhat weak on several of its floating point
formats. Some of the formats seem to give screwey results. It's hard to
find out why (see below).

Quote:>>SAS does have one of the better de*s I have seen.  But its other tools
>>are geared more for small projects.  For example its make is really stupid
>>and forces duplication.

>The SAS de* is pretty good. I have found the make utility to be
>ok, once you set it up it works fine.

The SAS/C de* is great - with one exception - it only knows about
one floating point format. It makes it pretty darn hard to debug if you
don't use the format that SAS uses. And the other modes have bugs, so if
you get a program to work with the default fp mode, and then attempt to
compile it and link it so that it uses the shared math libraries
instead, what do you do when it doesn't work right?

Quote:>Still SAS is good enough for me.

That's why I bought it... I wish thier customer support was better though.

>>Tal Lancaster

>--
>Colin Adams                                  
>Computer Science Department                     James Cook University

>'And on the eight day, God created Manchester'

--


| !chinet!uokmax!servalan!epmooch!ben     |  CEO, Seagate Technologies   |
 
 
 

DICE vs GCC

Post by Tal Lewis Lancast » Sun, 07 Apr 1991 02:38:45


 [cut...snip]

Quote:>I wouldn't say gcc is bug free but I have
>>found it more stable for my project than SAS or Aztec.   And I have been
>>producing 1.4 M executables with it!  So I wouldn't say gcc can't handle large
>>projects.
>yes, 1.4M executable is bigger than my small 250k exec. but I'm working
>to get it smaller not bigger :-)

yes, I hope to get that 1.4M down down a little bit too.  Maybe closer to 600K.

Quote:>  Because I am doing things that just can't be done with SAS or Aztec.
>Why not?

Well the main reason is I am creating object files greater than 32K (actually
some are around 80K).  SAS and Aztec can not handle object files > 32K.  Or to
be more precise a function call to another function in the same object file must
be < 32K apart.

Gee, why don't I just make object files < 32k (in other words write smaller C
files)?  Well I am not the one producing the C files, my computer is.  I have
been working on a compiler that uses C as the intermediate langauge and it is
the output from this compiler that is producing these large C files.  To make
the compiler produce smaller C files will mean a lot of changes to it.  I will
need to make these changes sometime...

Quote:>>SAS does have one of the better de*s I have seen.  But its other tools
>>are geared more for small projects.  For example its make is really stupid
>>and forces duplication.
>The SAS de* is pretty good. I have found the make utility to be
>ok, once you set it up it works fine.

For example, if you have the following dependency

fish.o:  spam.h

LMK will try to compile spam.c.  So you are forced to use

fish.o: fish.c spam.h

Also, if you have the macro

OBJ=  [ lots of files total length > 255]

and try

fish: $(OBJ)
        blink FROM $(OBJ) ...

This will lock up your computer and maybe even trash your hard-drive.
So you are forced to duplicate the contents of OBJ into a blink file.

Quote:>Still SAS is good enough for me.

Yes, I have to agree SAS is pretty good.  I am just pointing problems with it
that prevent me from considering it as a professional product.

>--
>Colin Adams                                  
>Computer Science Department                     James Cook University

>'And on the eight day, God created Manchester'

Tal Lancaster

 
 
 

DICE vs GCC

Post by Rob Tull » Sun, 07 Apr 1991 05:03:04


Well, I have not used DICE, but I have used GCC, PDC, ZC, and NORTHC. Of all
these, there is no question, GCC is the answer. I have had little to
no trouble porting things like diff, flex, and bison to my machine. It
is a memory hog and not very fast, but it has a much better pre-processor
than early releases of ZC and NORTHC. I used PDC up until I got GCC from
ab20 and now I would not go back. The last time I checked, the GCC port
was using the PDC front end to the compiler (gcc == ccx). Comments in
the readme files indicated that the real gcc front-end program was forthcoming.

With regard to gdb, I would love to see this program ported. I am real
tired of coding printf's into my source just to see what a variable is
being set to. If anyone has seen this running under 1.3, I would love
to hear about it.

With regard to large projects, If I can build packages like flex, bison,
and diff (which uses regex.c - very large C file) without incident - I
would say it is pretty clean. It has not yet failed me - wish I could
say the same about about some of the ARP calls (ASyncRun() argh!).

With regard to speed, anyone know why it is that blink takes so long
when you link to arp.lib? I have generated multiple libraries to link
to and adding this one always slows the link down on the order of minutes.

Rob Tulloh
--
INTERACTIVE Systems Corp.         Tel: (512) 343 0376 Ext. 116
9442 Capital of Texas Hwy. North  Fax: (512) 343 0376 Ext. 161 (not a typo!)

Austin, Texas 78759               GEnie: R.TULLOH (polled monthly)

 
 
 

DICE vs GCC

Post by Randell Jes » Sun, 07 Apr 1991 07:38:07




>>  Because I am doing things that just can't be done with SAS or Aztec.

>>Why not?

>Well the main reason is I am creating object files greater than 32K (actually
>some are around 80K).  SAS and Aztec can not handle object files > 32K.  Or to
>be more precise a function call to another function in the same object file must
>be < 32K apart.

        Easy, just use -r0 to turn off pc-relative bsr's (-b0 to use long
data addressing).

Quote:>fish.o:  spam.h

>LMK will try to compile spam.c.  So you are forced to use

>fish.o: fish.c spam.h

        Very annoying, true.  So use some other make (originally the make
was some separate lattice thing).

--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.

Disclaimer: Nothing I say is anything other than my personal opinion.
Thus spake the Master Ninjei: "To program a million-line operating system
is easy, to change a man's temperament is more difficult."
(From "The Zen of Programming")  ;-)

 
 
 

DICE vs GCC

Post by Matthew Dill » Sun, 07 Apr 1991 04:12:35





>>..

>>>...
>yes, 1.4M executable is bigger than my small 250k exec. but I'm working
>to get it smaller not bigger :-)

>  Because I am doing things that just can't be done with SAS or Aztec.

>Why not?

    For example, SAS/C and Manx have major limits on how large a
    preprocessor macro can be.  Both DICE and GCC allow arbitrarily
    sized macros.

    There are other examples, but the preprocessor limitations are
    the most obvious.

                                    -Matt
--


    891 Regal Rd.           uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

 
 
 

1. GCC vs DICE vs SAS C

Could someone post a side by side comparison between the 3 major C compilers?

Thanks.

--
-------------------------------------------------------------------------------
Dennis Grant                  Amiga 4000/030/6/120/40Mhz '882/IDEK 17" monitor

Charlottetown, PEI, Canada    There ain't no replacement for cubic displacement

2. Append message in body...

3. gcc vs Dice ?

4. discussion web wizard is messed up

5. gcc vs. gcc ?!?!

6. Openings for Solutions Architect with 8 years + Years of Exp in Bangalore

7. SAS/C vs. gcc vs. StormC

8. domainlets and Multiple clusters

9. DICE, GCC, or SAS/C ??

10. GCC/Dice

11. Source level debugger for DICE or gcc

12. Question about GCC and DICE?