Assembly language programming preferable to HLL ???
jo...@ima.uucp
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 Lev...@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
Compilers mailing list
Apparently-To: comp...@ima.uucp
In article <2...@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 (ccp...@watnot.UUCP)
Compilers mailing list
Apparently-To: ima!compilers
In article <2...@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)