Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Message-ID: <14807@smoke.brl.mil>
Date: 10 Jan 91 16:47:43 GMT
References: <325@generic.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 47

In article <325@generic.UUCP> ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes:
>Assembly language on the 65816 edges out the 8088 at almost half the clock
>rate?

For many typical applications, yes.  It varies with the application.

>I may not have majored in computer science, but doesn't both a compiler and
>an assembler generate machine language?

Eventually, of course.

>Logically both generate the same code for the same problem solution.

No, in fact compiled code is practically always different from what a human
writing in assembler would have used for the same problem.

>Therefore a given instruction that is good for Assmebler should also be good
>for Compiler.

No, because as indicated previously a human programming in assembler is in
a position to exploit even the most baroque and weird instruction set.  A
compiler, on the other hand, is an uncreative automaton that applied preset
rules to translate an unlimited variety of source code into machine code.
The code generation process generally does not attempt to exploit weird
instructions that are not of mnuch use in supporting general high-level
language programs.

>Needless to say, I know little about compiler design, but I have hand compiled
>C code on the 65816 and much of the syntax is directly translatable to
>assembly on a line for line basis (derefencing handles is an exception). 

But not for general compilation, it isn't.  Again, a human can recognize
efficient ways to translate a specific algorithm into machine instructions
that an automatic translation system would find infeasible.

>Which specific instructions are required in a computer achitecture to make
>easy for an HLL compiler?

It is not so much a matter of specific opcodes as it is of a suitable
architecture.  The best machine support for high-level languages would
include a highly structured regular instruction set, universally
applicable addressing modes, a uniform set of fast general-purpose registers,
both positive and negative offset indexed adressing, indirect addressing,
frame-oriented function linkage, and so forth.  The 65816 is woefully
deficient in most of these; those that it provides some support for in
general have incomplete, restrictive support, making the compiler have to
find some more general (and thus less efficient) solution to its needs.