🚀 go-pugleaf

>OK so this example is contrived but I hope you get the point.  Assembler
>will always run at least as fast as HLL if you use the same algorithm *and*
>you have sufficient time to implement that algorithm in assembler.

*and* the programmer is competent and writes code as well or better
than the HLL translator with same or less overhead. 

>680x0 is nice but it's not that nice.  It just doesn't compare to Macro-11 (-:

Well, how can *anything* compare to Macro-11?

>And all those 16 bit >limits )-: (on the 68000 at least).
Well, it was sure fun to address above 64K using macro-11 :-)

>it).  I think that the only sensible way to write in assembly language is to
>first write the code in Pascal and then (by hand) recode the Pascal into assembler.

If you remove the word "Pascal", then the above statement is true :-)
(Just a jest, son, now don't you get your feathers all ruffled;
 Pascal is just fine :-))
I say: use any language that you are comfortable with, get the 
@%^&$@! thing to work, and then worry later about optimizing:
by using better alg., by rewriting critcal sections into assembly
and then perhaps recoding whole thing to assembly.

The only problem with assembly  (from a  management point of view)
is that the pool of good assembly programmers is smaller than HLL.

>program because you know that the algorithm works and that the only errors were
>induced by the recode.  Also you have a working Pascal version to fall back on

Unless it works due to a bug in the compiler (it does happen....)  :-)

>if the wheels fall off and the deadline falls due.

Yeah, it'll be a real bummer if the whole thing is completed in assembly
but you can't figure the source of those address exceptions when
deadline comes around :-)  (Hey, what happened to the stack? :-))

Quick note on program size: It's hard to see why many new programs
are so *huge*, even taking in account use of HLL.  Is it due to redundancies
in the code?

-- 
					-george
					sukenick@sci.ccny.cuny.edu

Doctor:  "60 milligrams!