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

Tim Josling <tej@melbpc.org.au>
10 Jul 1999 01:26:24 -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)
[2 later articles]
| List of all articles for this month |

From: Tim Josling <tej@melbpc.org.au>
Newsgroups: comp.compilers
Date: 10 Jul 1999 01:26:24 -0400
Organization: Melbourne PC User Group
References: 99-07-023
Keywords: practice, C, assembler

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!


A total perspective should take these factors into account.


I did port some code from C to COBOL and found the lines of code
doubled. The main problem was lack of a macro facility in COBOL, so
you end up with a lot of repeated code. Of course what you are doing
with macros in assembler and C is creating another language (have a
look at the Xfree86 source code for an example).


HLLs can be more frustrating at times of course. Try writing an ascii
to hex conversion in COBOL for example. Now try making it portable
across machine architectures.


It would be helpful to see the actual source code of the examples
as it is difficult to validate the claims made when you can't see
the data.


Tim Josling


Mark William Hopkins wrote:
> An important lesson to be learned from experiences codified in the
> data below is that the relative (in)efficiencies of coding in either
> environment have little or nothing to do with the language used! It's
> all about style -- and to a large degree the quality of tools
> (particularly, assemblers) used with the project.


Post a followup to this message

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