Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw
From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: IIgs Unzip thing
Message-ID: <1991Mar25.222305.6194@nntp-server.caltech.edu>
Date: 25 Mar 91 22:23:05 GMT
References: <4388@orbit.cts.com> <50740@apple.Apple.COM>
Organization: California Institute of Technology, Pasadena
Lines: 27

shrinkit@Apple.COM (Andrew Nicholas) writes:

>Btw, Orca/C 1.1 (and 1.2 I'm assuming, mine hasn't come yet) will correctly
>compile the LZH source code and make it work.  It took something like 8 
>minutes to compress Finder v1.3 on a stock GS.  It took GS-ShrinkIt something
>like 23 seconds.  I remember doing this at KansasFest and came to the
>conclusion that the C source was almost useless -- even with all of Orca/C's
>optimizations >ON< (which isn't saying much, because the output which was
>produced by the compressor didn't match the output produced when optimizations
>were left off... hence my distrust of Orca/C 1.1's optimizer)... even with

Andy, learn something about Orca/C. It does not produce efficient code for lots
of simple things that are obvious to us assembly programmers. Also, the
optimizer sometimes exposes bugs in the code generator OR bugs in the program
itself that are usually hidden by 'forgiving' C implementations.

Using compiled languages for time-critical code never makes sense unless the
compiler is unspeakably awesome and efficient.

That C source is extremely useful -- the critical loops can be hand-compiled
into machine code and the non-critical sections can be left in C. I wrote LHG
originally in C, tested it in C, and then recoded the critical sections in
assembly. When I finally get a decent interface on the !@&*$@! thing you can
all see how well this method works. 

Todd Whitesel
toddpw @ tybalt.caltech.edu