Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!shrinkit
From: shrinkit@Apple.COM (Andrew Nicholas)
Newsgroups: comp.sys.apple2
Subject: Re: IIgs Unzip thing
Message-ID: <50784@apple.Apple.COM>
Date: 26 Mar 91 03:31:54 GMT
References: <4388@orbit.cts.com> <50740@apple.Apple.COM> <1991Mar25.222305.6194@nntp-server.caltech.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 58

In article <1991Mar25.222305.6194@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:

>Andy, learn something about Orca/C.

I've learned lots about Orca/C.  I've learned that it's not always worthy
of my trust in the correctness of the code it is generating.  This is as of
v1.1 -- I really hope v1.2 is better.

>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.

Btw, I wasn't slamming Orca/C, I was slamming the C code which I was using for
the LZH implementation -- the C code just isn't all that efficient in and of
itself.  Yeah, sure, you could go in a tweak routines to use assembly, but in
this particular case, I doubt that much would come of it -- I think you'd need
to rewrite major parts of the algorithm itself to get substantial speed
increases that people could live with.

Which, I suppose, isn't so much an indictment of the C code, but rather of
the algorithm itself -- or, at least this implementation of the LZH algorithm.

Am I making any more sense?

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

I know that, Todd.  I ain't completely stooopid.  ;-)

Also, you took what I was saying much too generally -- I wasn't saying that
All C code is slow and inefficient, or that all C object produced by Orca/C
is slow and inefficient... but in this case, both appear to be true.

>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.

Yes, and I still think you'll have something which is extremely slow as far as
the LZH source code goes.  I would love to have someone prove me wrong, but
I don't see that happening...

>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. 

Want to elaborate a little?  What's LHG?  Some variant of LHA?

>Todd Whitesel

andy

-- 
Andy Nicholas		  GEnie & America-Online: shrinkit
Apple Computer, Inc.  	 	      CompuServe: 70771,2615    
Apple IIGS System Software		InterNET: shrinkit@apple.com

I'm doing this on my own time, so I don't speak for Apple.