Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!stephens
From: stephens@latcs1.oz.au (Philip J Stephens)
Newsgroups: comp.sys.apple2
Subject: Re: languages (compilers and assemblers)
Message-ID: <7520@latcs1.oz.au>
Date: 28 Mar 90 07:33:20 GMT
References: <39854@apple.Apple.COM>
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 81

In article <39854@apple.Apple.COM>, stadler@Apple.COM (Andy Stadler) writes:
> 
>   A compiled program is easier for the PROGRAMMER to look at and understand.

  Correction: A _well_written_ program in a high-level language is easier to
understand. :-)  The object code would also be "easier" to read, but it would
never be optimised to the greatest degree possible.

  Now, before I continue, remember I am talking about an Apple ][ computer,
not a Unix box or some other such machine.  Everyone knows you don't bother
using assembly on a mini-computer.

> Everyone keeps talking about cycle-by-cycle style optimizations.  But that's
> only half the game.  It is equally important to optimize your algorithms,
> data structures, and program execution.

  Aha!  Remember, though, that most compilers only _do_ cycle-by-cycle style
optimizations!  The rest is up to the programmer.  Whether you are writing in
a high- or low-level language, you're going to have to write good algorithms
in the first place.  Depending on the problem you are trying to solve, you may
end up with code that is more difficult to understand once you've optimised
the solution. 

> No matter how well structured, an assembly program is longer (to the
> programmer - more lines of code) and thus harder to read and "internalize".
> You are forced to look at more details, and therefore less high-level
> structure.  Let's face it, we're not perfect, we have limited attention
> spans, and we need all the help we can get.

  If you are claiming that assembly programs are always going to be longer
than the equivalent C source, then you've not used assembly much.  On a
statement-by-statement basis, this is always going to be true, and since
compilers operate on such a basis, they can't produce the best code.
  However, write an algorithm directly in assembly, and you can optimise to
such an extent that often the resulting code will be far shorter than the
ASCII text in the C source itself!  It will certainly be shorter than the
compiled object code.
  You may think that it takes too much effort to write an algorithm efficiently
in assembly due to the lack of high-level structures.  Bollocks!  You've just
got to approach the problem in different directions, that is all.  The truth
is, high-level structures tend to be far more restrictive in the ways they
let you express the solution; in assembly, you're got complete freedom in how
you are going to write the algorithm.

  Why do you think people prefer C over Pascal?  Answer: because C is less
structured!  As a result, it is more difficult to program in C, but you can do
a hell of a lot more in it compared to Pascal.
  The same applies to assembly language over any high-level language.  A bit
harder to program, certainly requiring a different approach, but the results
may be worth the trouble.

> I agree, but only to a point.  Macro libraries or no, I can write code MUCH
> faster in Pascal than I can in assembly.  And the less time it takes me to
> write the program, the more time I have to debug, measure, and THEN optimize.

  But again, not applicable if you're writing a program on an Apple ][ that has
lousy speed and an inapproapiate microprocessor that isn't designed to run
code from a high-level language compiler.  Pascal may be easy to write code
in, but you'll never get the speed you want (if speed is an issue, of course).

> Please understand that when you compile a program, you don't just get the
> compiler output, you also get a whole bunch of library code to go with it.
> Problem is, the library code is large and generalized. 

  There's never been any doubt that library code takes up the most space.
Look at any Unix executable and you'll be bowled over by the number of blocks
taken up.
  I agree that compiled code can be quite compact - just look at the output
from Turbo Pascal, and you'll see this.  But it is never as compact as assembly
code written directly by the programmer.  

  Then again, why are we arguing about this?  Each has it's own place, assembly
language more so on an Apple ][.  That's just the way it is.

> --andy    stadler@apple.com

</\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\>
<  Philip J. Stephens                ><   "Many views yield the truth."        >
<  Hons. student, Computer Science   ><   "Therefore, be not alone."           >
<  La Trobe University, Melbourne    ><          - Prime Song of the viggies   >
<\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>