🚀 go-pugleaf

In article <6105@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes:
>In article <10330083@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes:
>> ... I'm sorry, and you can disagree, but there is _no way_ that 
>>high level code can match the size and speed compactness of assembly language
>>programming. This has nothing to do with using tricks of the chip, or black 
>>magic, but because high level languages require support routines and the
>>like which assembly language code can avoid.
>
>True enough, if you have an infinite amount of time; there is also _no way_
>that a team of programmers can develop and test code in the same amount of
>time using low-level tools (assembly language).  You just can't manage a large
>amount of arbitrary complexity without high level tools. ...
>
>Assembly language is useful in it's place, but only there.  I would wager that
>most of the speed and compactness improvements are due to better work habits
>forced on you by the lack of type checking, etc., of assembly language.  The
>same skills would serve you just as well in any software environment.
> 

Several comments.
	1) OS 360 was written in assembly language. Even today there are not a
       whole lot of programs equivalent in either size or complexity.
	   Remember, we're talking somewhere around 1965-1968. Read
	   "The Mythical Man Month" by ?? Brooks. The issue isn't complexity,
	   it's lines of code. In most cases you get more work per line of HOL
	   code than you do per line of assembly. The only reason HOLs are
	   considered an advantage is because most programmers are really coders
	   Automate coding from design specs and you lose all advantage of HOLs.
	   (Of course the "design language" now becomes the HOL and languages like
	   C, LISP, SMALLTALK etc become "assembly languages" and are inefficient
	   low level tools.)
	2) One of the major savings in using assembly language IS due to "tricks
	   of the chip". I remember doing assembly programming on a CDC 6600
	   (1975). Two techniques in particular were used to speed up programs;
	   First, we coded inner loops to keep the entire intruction stream in
	   the instruction cache - no memory access (for instructions) - major
	   gain; second, we interleaved instructions to take advantage of mutually
	   independant asynchronous functional units - the units only synchronized
	   to access common registers - depending upon the task, this could gain
	   little to a lot.
	3) The other major saving in using assembly language is "optimization". Yes,
	   having to include support code and other general library routines from
	   the compiler cuts down on code efficiency, but the major problem is that
	   most commercial compilers generate horrible code. Hand coding in assembly
	   makes up for the stupidity of compilers. Of course, good compilers can be
	   written but I suspect that the R&D effort involved would push the
	   potential selling price out of the reach of most buyers. However, take a
	   look at the IBM FORTRAN H (optimizing) compiler or the original PASCAL
	   compiler written specifically for the CDC 6600.
	4) It's still a truism that appropriate algorithms buy you far more than
	   hand optimization. However, once you have a working program you can
	   substantially improve it's speed by analysing the bottlenecks and
	   recoding the critical procedures (or loops) in assembly language. As
	   an aside, the latest MacTutor has an interesting article on optimizing an
	   assembly language routine.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
UUCP: {sun,decvax,linus}!cvbnet!pcolby ||| "We has met the enemy and he is us."
UUCP: pcolby@robbie.prime.com          |||                           Pogo
CSNET: pcolby@robbie.prime.com         |||