Path: utzoo!attcan!uunet!cs.utexas.edu!usc!snorkelwacker!mintaka!dcw
From: dcw@lcs.mit.edu (David C. Whitney)
Newsgroups: comp.sys.apple2
Subject: Re: languages (compilers and assemblers)
Message-ID: <1990Mar27.155831.7243@mintaka.lcs.mit.edu>
Date: 27 Mar 90 15:58:31 GMT
References: <9003232001.AA00592@apple.com> <12423@smoke.BRL.MIL> <7494@latcs1.oz. <1990Mar25.210033.14719@world.std.com> <7509@latcs1.oz.au> <12435@smoke.BRL.MIL> <3880@sage.cc.purdue.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: MIT Spoken Language Systems Group
Lines: 55

In article <3880@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes:
>>Article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes:
>>>  It seems to me that most programmers ought to be write better code than a
>>>compiler; ...
>
>Article <12435@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) replies:
>>involved, compiled code can run anywhere from somewhat faster (yes!) to
>>several times slower.
>
>    Compilers translate statements into machine code while assembliers
>practicly directly convert to machine code.  The only way compiled code
>can run faster is a sloppy programmer.  A compiler is able to clean up
>some of the mess and thus make faster code, but with a good programmer,
>the compiler would have to be enormesly complex (and slow) to compete.

>    Something else about assembly that I feel important hasn't been
>mentioned.  Assembly code is more compacted!  The shorter the program,
>the more evident this becomes.  See if a compiler can create the "hello
>world" program in about two dozen bytes!  Not two dozen Ks, but bytes.
>One of the reasons for this comes from numbers that only need one byte
>often use two or four!

> Y_,_|[]|   Eric Mulholland
>{|_|_|__|   aj0@sage.cc.purdue.edu
>//oo--OO    ...!pur-ee!sage.cc!aj0

Please remember that there are GOOD compilers out there. The 65816 is
pretty crippled, and it's just TOO HARD to write a whiz-bang compiler
for it.

Let me tell you, you DON't want to write programs on a RISC (say, a
Sun SPARC) or any other pipelined CPU in assembler. You'll pull all
your hair out. In this instance, a compiler WILL ALWAYS produce MUCH
better code than a person could. In general, optimizers are pretty
good IF the hardware they compile to has enough resources (ie,
registers). With today's CPUs, compilers will outperform direct
assembly coding nearly all of the time.

Optimizers exist (although I don't know of one for the //). They're
complicated in overall design, but each optimization technique is
pretty simple. The thing to do of course is to build a 65816 output
generator into gcc; compile gcc into 65816; move it to the apple //gs.
Gcc has some pretty good optimization stuff built in. It would run
gawd-awful slow (it's already sorta slow on my SPARC).

The better idea is to make the 65832 have several registers (16 or
32). The A, X, Y, SP, etc would be mapped onto the first n registers
so that older stuff will work properly. THEN, compilers would be much
happier.

--
Dave Whitney
dcw@sun-bear.lcs.mit.edu  ...!mit-eddie!sun-bear!dcw  dcw@athena.mit.edu
My employer pays me well. This, however, does not mean he agrees with me.
I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.