Re: High Level Language vs Assembly

Jim Granville <jim.granville@designtools.co.nz>
22 Feb 2001 23:58:52 -0500

          From comp.compilers

Related articles
High Level Language vs Assembly francis.doyle@donovandata.com (2001-02-17)
Re: High Level Language vs Assembly jim.granville@designtools.co.nz (Jim Granville) (2001-02-22)
Re: High Level Language vs Assembly rhyde@transdimension.com (Randall Hyde) (2001-02-23)
Re: High Level Language vs Assembly sophie.wilson@broadcom.com (Sophie Wilson) (2001-02-23)
Re: High Level Language vs Assembly iank@idiom.com (2001-02-23)
Re: High Level Language vs Assembly thp@hill.cs.ucr.edu (Tom Payne) (2001-02-25)
Re: High Level Language vs Assembly walter@bytecraft.com (Walter Banks) (2001-02-25)
Re: High Level Language vs Assembly walter@bytecraft.com (Walter Banks) (2001-02-25)
[24 later articles]
| List of all articles for this month |
From: Jim Granville <jim.granville@designtools.co.nz>
Newsgroups: comp.compilers
Date: 22 Feb 2001 23:58:52 -0500
Organization: Mandeno Granville elect
References: 01-02-094
Keywords: design, performance
Posted-Date: 22 Feb 2001 23:58:51 EST

francis.doyle@donovandata.com wrote:
>
> Hi,
> When I took a compiler class in Grad School, my professor was
> adamant about the efficiency of code produced by new high level
> language compilers. He stated that a human assembly language writer
> was no longer able to compete with these compilers (unless, of course
> you consider something like Microsoft VB...Ha Ha). His arguments were
> convincing, but I was looking for some actual numbers to back this up
> (ie; RECENT performance comparisons). Any help would be greatly
> appreciated (as I work in an IBM Mainframe assembly shop and this sort
> of talk gets me treated like a heretic).


Some examples are on our web, at
http://www.designtools.co.nz/modbench.htm These are for
microcontroller apps, where bytes matter more than PC's


He is largely correct: At the most detailed, hand ASM can lead, but it
is an unsustainable effort across a whole project, and more commonly
is counter productive.


  Examples:
There is a tendency to believe that because coding is done in ASM, the
SW _MUST_ be efficent, which is often flawed.


  An example just last week has an Assembler jump table of a customer,
reduced 30% in size when moved to HLL, because it was written as an
array of LCALLs, not an array of Address stores.
  The code looked tight, but a simple algorithm change reduced the size
significantly.
  Of course, it could be recoded in ASM the same, but the point is it
was not seen.


  A couple of years ago we recoded a keyboard routine, written in ASM
as a massive case statement, into two nested scan loops, about 8 lines
of HLL - and code dropped from ~200 bytes to ~59 bytes.
  The CASE statement was easier to code in ASM, and started life small,
but grew over the life of the design to something more massive.
  Again, the same algorithm change could have been affected in ASM, but
again it was not even looked for - this programmer did not (initially)
believe it was inefficent at all :-)


  Rather than the One OR other argument often seen, our advice to
programmers is to understand _BOTH_ ASM and HLL coding, and be able to
mix them in the right amounts.


  Algorithm is far more important than language, and you can trial many
more algorithms per unit time in HLL, than in ASM.


  It also pays to choose a HLL that matches the CORE, and for the C51's
Modula-2/IEC1131 is an excellant selection.


- Jim G.
--
======= 80x51 Tools & IP Specialists =========
= http://www.DesignTools.co.nz
[I entirely agree. You can do tighter inner loops in assembler, but HLLs
make it practical to use more sophisticated algorithms and data structures.
-John]





Post a followup to this message

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