Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!cs326ag From: cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) Newsgroups: comp.sys.amiga.programmer Subject: Re: DICE vs GCC Message-ID: <1991Apr5.153411.10189@ux1.cso.uiuc.edu> Date: 5 Apr 91 15:34:11 GMT Organization: University of Illinois at Urbana Lines: 80 In article 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