Assembly language programming preferable to HLL ???
jo...@ima.uucp
> 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 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
jo...@ima.uucp
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]