[mod.compilers] Assembly language programming preferable to HLL ???

johnl@ima.UUCP (12/03/86)

	Have you seen an article in "Computer Language" magazine
of Oct. 86 about "Universal assembly language" ?

    This article claims that it is (always/usually) better to
use assembly language rather than HLL. (any). this is based on the 
following claims: 

    1. The ONLY siginificant advantage of HLL is a shorter CODING time.
    2. Design, documentation, testing time is (almost) the same in both cases.
    3. The assembly program will run 2-5 times faster.
    4. So, after enough runs of the program the coding time gap will be 
       swallowed. From then on, the assembly program gains non-stop.

   Seems to me that this does not hold water.
     
    1. No mention of changes/maintenance issues anywhere.
    2. I strongly question ALL of the above assumptions. 
    3. As one of the compiler writers for NS , If assembler programs
	, as a rule , ran 2 times faster than our compiler, 
	I would be greatly surprized and FIX THE COMPILER !
    
   The autor also suggests a "UNIVERSAL ASSEMBLER" to run on many machines.
I think FORTH already fits the bill, & has many other advantages.

			Any Comments,  netlanders ?
-- 
orr%nsta@nsc			 IBM's motto: Machines should work,
                                              People should think.
                                 Orr's remark: Neither do.
Disclaimer: Opinions, come home. All is forgiven. Papa.
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (Compilers mailing list) (12/04/86)

Real-sender:

Apparently-To: compilers@ima.uucp


In article <277@ima.UUCP> Orr Michael writes:
>
>	Have you seen an article in "Computer Language" magazine
>of Oct. 86 about "Universal assembly language" ?

Yes, I have.  I don't intend to be too hostile, but I laughed when I read it.
"Computer Language" seems to need better articles/editing.

>    This article claims that it is (always/usually) better to
>use assembly language rather than HLL. (any). This is based on the 
>following claims: 
>
>    1. The ONLY siginificant advantage of HLL is a shorter CODING time.
>    2. Design, documentation, testing time is (almost) the same in both cases.
>    3. The assembly program will run 2-5 times faster.
>    4. So, after enough runs of the program the coding time gap will be 
>       swallowed. From then on, the assembly program gains non-stop.
>
>   Seems to me that this does not hold water.
>     
>    1. No mention of changes/maintenance issues anywhere.
>    2. I strongly question ALL of the above assumptions. 
>    3. As one of the compiler writers for NS , If assembler programs,
>	as a rule, ran 2 times faster than our compiler, 
>	I would be greatly surprised and FIX THE COMPILER !
>    
>   The author also suggests a "UNIVERSAL ASSEMBLER" to run on many machines.
>I think FORTH already fits the bill, & has many other advantages.
>
>			Any Comments, netlanders ?

You're right, it doesn't hold water.  First, for the reasons you mentioned,
and secondly because a universal assembler is essentially impossible.

The advantage assembler has over HLL's is that the programmer can use
idiosyncrasies of the architecture to the best advantage.  A compiler
can do this to some degree, but it would take a mighty good optimizer
to recognize when to use the string instructions some machines provide,
even though they can provide a very worthwhile > 2x speed increase.

A universal assembly language, on the other hand, doesn't let a programmer
use *any* tricks - and doesn't provide an optimizer which *can* use them.
In short, *slow*.  Of course, you could always include a whole bunch of
common (but not universal) instructions (like, say, multiply) as macros,
but then you're just chasing HLL's up the evolutionary tree.  The basic
premise needs serious work.

P.S. I agree - for very tight control of the machine and good speed,
     use Forth.  It produces smaller code than a lot of compiled HLLs,
     is fast enough for most purposes, and you, the programmer, know
     *exactly* what's going on inside the machine.  And, of course, you
     can easily recode any critical bits into assembler.

	-Colin Plumb (ccplumb@watnot.UUCP)
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (Compilers mailing list) (12/04/86)

Real-sender:

Apparently-To: ima!compilers


In article <277@ima.UUCP> Orr Michael writes:
>
>	Have you seen an article in "Computer Language" magazine
>of Oct. 86 about "Universal assembly language" ?
>
>   The autor also suggests a "UNIVERSAL ASSEMBLER" to run on many machines.
>I think FORTH already fits the bill, & has many other advantages.
>
>			Any Comments,  netlanders ?

Yeah, don't read Computer Language.  I glance at copies in bookstores to
verify that, yes, this month they have still more inaccurate/superficial
articles.  The idea of a "universal assembler" has been resurfacing every
once in a while for the last thirty years, but is still a silly idea.
Assembly language must by its nature reflect the underlying hardware, so
a universal assembler requires all machines to have the same architecture.
Folks who think a universal assembler is possible have probably only
studied about two processors and supposed that they all look the same.
(Try finding something that Vax and a Cray have in common!)

Forth is not a "universal assembler", it is a high-level (well, sort of)
programming language.  Either: 1) it is compiled, in which case it has
the same defects attributed to Fortran etc compilers, or 2) it is interpreted,
but interpreted code is almost always slower than compiled code, or 3)
the machine executes Forth directly, which doesn't do anything for the
performance of Forth on other machines.

There was an interesting remark in an old paper on Interlisp-D, I think,
to the effect that moving much of the system from low-level languages
into compiled Lisp resulted in an overall performance gain, just because
the compiler performed consistently well, while the human coders did not.

							stan shebs
							(shebs@utah-cs)
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (12/05/86)

>     3. The assembly program will run 2-5 times faster.

>     3. As one of the compiler writers for NS , If assembler programs
> 	, as a rule , ran 2 times faster than our compiler, 
> 	I would be greatly surprized and FIX THE COMPILER !
					====================

Precisely.  What the CL author may have been reacting to, however, is
the very poor state of compilers on the market.  The latest BYTE magazine
has benchmarks on performance of several PC Pascal compilers.  Most are
so $%#@ing slow that it makes you cry.  And then Turbo makes the matter 
"worse" by proving that compilers don't have to be slow at all!

Maybe the availability of different compilers will get compiler writers
thinking about their art form better.

(And while you're at it, fix the linkers too!)
[I am going to wrap up this discussion unless somebody has something
particularly different to contribute.  It appears we all agree that A) micro
computer compilers are of generally poor quality, B) good compilers exist, which
produce code about as good as hand-coded, and C) the author of the CL article
was not well-informed about compilers outside the micro world.  Oh yes, and a
machine-independent assembler is an oxymoron, unless perhaps you consider a
language like C to be one.
-John]
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (12/12/86)

Cc:

I recently had this argument ( in specific the situation was comparing
a high quality Fortran 77, an optimized C, and assembler) and received
a very different rationale for the superiority of assembler.  It was
empirically argued that persons with sufficient skill to make the
assembler code function also had the requisite skills to understand
the problem and solve it properly.  Persons skilled in High level
languages usually did *NOT* (well proven by the code that I am
presently repairing) have the background needed.

The basic problem with HOL's is that the programmers did not
understand the very strict and complex timing rules that must be
followed to make a radar controller and signal conditioner work in a
cost effective manner.  Assembler programmers did understand timing
rules.  There was a subsidiary problem concerning a more generic
awareness of the behaviour of hardware.

There was also a secondary performance argument, but so far I have
shown that optimized C is running within 80% of the assembler versions.
This skill issue is the first substantive argument that I have ever
seen in favor of assembler.  It only applies to one class of
application, but it may be valid.  Is this observed correlation of
skills accurate?  Is it based on some causal relationship?
-- 
				Rob  Horn
	UUCP:	...{decvax, seismo!harvard}!wanginst!infinet!rhorn
	Snail:	Infinet,  40 High St., North Andover, MA
[Your moderator finds this problem pretty spurious.  Sure, there are problems
with such strong real-time constraints that you have to program in machine
language and count every cycle.  For the other 99% of the problems, I've seen
plenty of inept assembler programmers and skilled HOL programmers.  The inept
assembler programmers tended to waste a lot of time hand-optimizing code where
the size and speed didn't make any difference, then program a bubble sort in
the inner loop because the data structures for heapsort are too complicated to
write in assembler. -John]
-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request