Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!ucrmath!gibson!rhyde
From: rhyde@gibson.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Re- HLLs vs. Assembly
Message-ID: <13499@ucrmath.ucr.edu>
Date: 10 Apr 91 18:03:40 GMT
References: <9104060651.AA18946@apple.com> <1991Apr6.100927.21953@nntp-server.caltech.edu> <1991Apr9.150402.563@latcs2.lat.oz.au> <15782@smoke.brl.mil>
Sender: news@ucrmath.ucr.edu
Reply-To: rhyde@gibson.ucr.edu (randy hyde)
Lines: 19

>> Any HLL should be exploited in terms of its abstract model rather than the
>> low-level machine model (due to portability concerns)

Absolutely!  If you're going to use a HLL, you should exploit that HLL,
not attempt to write "assembly language" in that HLL.  This is what most
people do to a large degree.  That's why assembly language programmers
tend to produce better assembly language code than compilers, not
because of compiler technology, but because their programming paradigm
takes into account the low-level machine architecture.

Clearly if portability is your overriding concern and you *must* use a
HLL, getting down to the lowest level possible in C may produce
performance benefits on certain architectures but fail miserably on
others.  The 65816 vs. 68000 is a good example of this.

OTOH, if portability is not a concern (you're only going to market your
program on one machine) attempting to "optimize" C for the architecture
is almost as much work as writing in assembly in the first place and you
still won't do as good.