tjhayko@THUNDER.LAKEHEADU.CA (04/02/91)
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 * * tjhayko@thunder.lakeheadu.ca * 807-344-7460 80MB online* * tjhayko@LAKEHEAD.BITNET * NOTE: I'm not the sysop * ********************************************************** QUIT
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/04/91)
In article <9104021420.AA10848@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: > > >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 * >* tjhayko@thunder.lakeheadu.ca * 807-344-7460 80MB online* >* tjhayko@LAKEHEAD.BITNET * NOTE: I'm not the sysop * >********************************************************** > >QUIT -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
cpca@marlin.jcu.edu.au (Colin Adams) (04/04/91)
In article <9104021420.AA10848@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: > > >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 * >* tjhayko@thunder.lakeheadu.ca * 807-344-7460 80MB online* >* tjhayko@LAKEHEAD.BITNET * NOTE: I'm not the sysop * >********************************************************** > > > >QUIT -- Colin Adams Computer Science Department James Cook University Internet : cpca@marlin.jcu.edu.au North Queensland 'And on the eight day, God created Manchester'
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/04/91)
>In article <1991Apr5.030228.28756@marlin.jcu.edu.au> cpca@marlin.jcu.edu.au (Colin Adams) writes: >In article <1991Apr4.180217.19773@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >> 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). >>SAS does have one of the better debuggers 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 debugger is pretty good. I have found the make utility to be >ok, once you set it up it works fine. The SAS/C debugger 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? >Still SAS is good enough for me. That's why I bought it... I wish thier customer support was better though. >>Tal Lancaster >>tll@tybalt.caltech.edu > > >-- >Colin Adams >Computer Science Department James Cook University >Internet : cpca@marlin.jcu.edu.au North Queensland >'And on the eight day, God created Manchester' -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (04/05/91)
cpca@marlin.jcu.edu.au (Colin Adams) writes: >In article <9104021420.AA10848@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: >> >> >>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 debuggers 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 * >>* tjhayko@thunder.lakeheadu.ca * 807-344-7460 80MB online* >>* tjhayko@LAKEHEAD.BITNET * NOTE: I'm not the sysop * >>********************************************************** >> >> >> >>QUIT >-- >Colin Adams >Computer Science Department James Cook University >Internet : cpca@marlin.jcu.edu.au North Queensland >'And on the eight day, God created Manchester' Tal Lancaster tll@tybalt.caltech.edu
cpca@marlin.jcu.edu.au (Colin Adams) (04/05/91)
In article <1991Apr4.180217.19773@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >cpca@marlin.jcu.edu.au (Colin Adams) writes: > >>In article <9104021420.AA10848@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: >>>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 >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? >SAS does have one of the better debuggers 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 debugger 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 >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 >tll@tybalt.caltech.edu -- Colin Adams Computer Science Department James Cook University Internet : cpca@marlin.jcu.edu.au North Queensland 'And on the eight day, God created Manchester'
cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (04/05/91)
In article <ben.5626@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >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). >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. >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. > >| ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | 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
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/06/91)
In article <1991Apr5.030228.28756@marlin.jcu.edu.au> cpca@marlin.jcu.edu.au (Colin Adams) writes: >In article <1991Apr4.180217.19773@nntp-server.caltech.edu> tll@nntp-server.caltech.edu (Tal Lewis Lancaster) writes: >>cpca@marlin.jcu.edu.au (Colin Adams) writes: >>.. >>>In article <9104021420.AA10848@thunder.LakeheadU.Ca> tjhayko@THUNDER.LAKEHEADU.CA writes: >>>... >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 -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
robtu@itx.isc.com (Rob Tulloh) (04/06/91)
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!) Arboretum Plaza One, Suite 700 Net: robertt@isc.com (polled daily) Austin, Texas 78759 GEnie: R.TULLOH (polled monthly)
dale@boing.UUCP (Dale Luck) (04/07/91)
In article <ben.5626@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>> Because I am doing things that just can't be done with SAS or Aztec. >>Why not? >Things like the X >window system sources hose up SAS/C, but GCC will compile them fine. Up until 5.04 there were too many bugs in SAS/C to compiler X source code, however after 5.04 became available we finally were able to ram the client source code through SAS/C. Compilers don't just get better by themselves. There are so many things that can go wrong and there are so many ways that programmers stretch the language. We first tried porting the client side of X11 to the Amiga with both Aztec<5.0 as well as Lattice < 5.0, absolutely hopeless. When 5.0 came out we got about 95% of the way there. But some things like offsetof macros were screwed. Some of these problems are easy to find because it compiler complains and gives up. However these bugs that we submitted as well as many others did get fixed so that 5.04 was finally up to the job. It did a good enough job so that at least the code compiled and would link. Now all we have to worry about are the subtle bugs that are just bogus code. Many of these have gotten fixed as well. But still Some of these exist in the 5.10a compiler. All we can do as companies with products on the market that depend on compilers is to help the companies find the bugs and hope they have timely fixes. SAS has proven to me that they support their product and that is one of the reasons we recommend SAS/C for people doing X11 programming on the Amiga. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/07/91)
In article <1991Apr5.153411.10189@ux1.cso.uiuc.edu> cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) writes: >In article <ben.5626@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>Try compiling the GNU regexp code with SAS/C and the -O option. Then >>.. >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). Actually, I would be interested in the code. DICE does not do any major optimizations and I would certainly expect SAS/C to beat it with -O turned on, but as you noted it *does* compile things quickly :-) Still, half as fast sounds like I have a little work to do. >>| ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | > >Loren J. Rittle -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA