Re: Empirical data: assembly source vs. HLL source.

David Chase <chase@world.std.com>
11 Jul 1999 19:36:51 -0400

          From comp.compilers

Related articles
Empirical data: assembly source vs. HLL source. hunk@csd.uwm.edu (Mark William Hopkins) (1999-07-06)
Re: Empirical data: assembly source vs. HLL source. jsture@nortelnetworks.com (John Sture) (1999-07-10)
Re: Empirical data: assembly source vs. HLL source. tej@melbpc.org.au (Tim Josling) (1999-07-10)
Re: Empirical data: assembly source vs. HLL source. chase@world.std.com (David Chase) (1999-07-11)
Re: Empirical data: assembly source vs. HLL source. djb@koobera.math.uic.edu (1999-07-12)
Re: Empirical data: assembly source vs. HLL source. johnmce@world.std.com (1999-07-12)
Re: Empirical data: assembly source vs. HLL source. t.hutt@worldnet.att.net (Taylor Hutt) (1999-07-12)
Re: Empirical data: assembly source vs. HLL source. pmai@acm.org (1999-07-14)
Re: Empirical data: assembly source vs. HLL source. darcy@moa.CS.Berkeley.EDU (1999-07-14)
Re: Empirical data: assembly source vs. HLL source. adrian@dcs.rhbnc.ac.uk (1999-07-14)
[1 later articles]
| List of all articles for this month |
From: David Chase <chase@world.std.com>
Newsgroups: comp.compilers
Date: 11 Jul 1999 19:36:51 -0400
Organization: None
References: 99-07-023 99-07-038
Keywords: assembler, comment

Tim Josling wrote:
> We noticed this a long time ago - C is not necessarily any more
> concise than assembler. However:
>
> 1. Assembler is not portable. I got sick of learning new assemblers. I
> got sick or porting code from one machine code to another. This is
> what killed some of the early operating systems and why Unix (written
> in C) is so successful.
>
> 2. Assembler is harder for many people - a greater number of people
> are capable or coding C and especially COBOL than assembler.
>
> 3. Assembler is more prone to bugs in my experience and I spent more
> time debugging assembler programs - as long as the HLL compiler is not
> itself buggy!


4. Assembly language syntax is brain-dead, far more than should be
necessary in this day and age. We do not lack for cheap cycles in
our development platforms. It's just insane that I write


    add r1,r3,r2 (quick, which is the destination operand?)


and even more insane that here on the x86, Microsoft and Gcc arrange
their operands in orders different. This is an invitation to pilot
error.


Of course, there is still brain-dead syntax in higher-level languages.
I find myself, dummy that I am, unable to keep track of the relative
precendence of the C/C++/Java casting, selection, invocation,
and array index operators. Most of the people I work with are
similarly impaired; I think this problem is widespread.
Think how much simpler life would be if we could ditch those
fragdabbling prefix operators and use postfix notation for casts,
for example:


    x[i].clone().(Vector).get(3)


instead of


    ((Vector)(x[i].clone())).get(3)


In a world of Turing-equivalent parentheses-matching, both are
equally unambiguous, but my poor brain fails the Turing test
(that is, it fails to performn this sort of menial algorithmic
task as well as a computer) and distinctly prefers the first
one, even though I have spent years programming in languages
that use the second syntax, so I "ought" to know it better.


If I didn't know that self-selected polls are bogus, I'd
be tempted to run a poll to see which people generally
thought was easier to parse.


--
David Chase -- chase@naturalbridge.com
NaturalBridge LLC -- http://www.naturalbridge.com
BulletTrain bytecode compiler -- when you can't wait for performance


[There's no reason that assemblers have to have awful syntax. About
30 years ago I used Niklaus Wirth's PL360, which was basically a S/360
assembler with Algol syntax and a a little syntactic sugar like while
loops that turned into the obvious branches. It really was an
assembler, e.g., you had to write out your expressions with explicit
assignments of values to registers, but it was nice. Wirth used it to
write Algol W, a small fast Algol subset, which was a predecessor to
Pascal. As is so often the case, Algol W was a significant
improvement over many of its successors. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.