Re: Optimizing in assembly language

Jim Granville <jim.granville@designtools.co.nz>
4 Mar 2001 01:39:08 -0500

          From comp.compilers

Related articles
Optimizing in assembly language rhyde@transdimension.com (Randall Hyde) (2001-03-01)
Re: Optimizing in assembly language jim.granville@designtools.co.nz (Jim Granville) (2001-03-04)
Re: Optimizing in assembly language sunni@speakeasy.net (Shankar Unni) (2001-03-04)
Re: Optimizing in assembly language ts3@ukc.ac.uk (T.Shackell) (2001-03-08)
Re: Optimizing in assembly language jguthrie@brokersys.com (Jonathan Guthrie) (2001-03-08)
Re: Optimizing in assembly language l-desnogues@ti.com (Laurent Desnogues) (2001-03-08)
Re: Optimizing in assembly language ceco@jupiter.com (Tzvetan Mikov) (2001-03-08)
Re: Optimizing in assembly language adrian@sartre.cs.rhbnc.ac.uk (A Johnstone) (2001-03-08)
[12 later articles]
| List of all articles for this month |

From: Jim Granville <jim.granville@designtools.co.nz>
Newsgroups: comp.compilers
Date: 4 Mar 2001 01:39:08 -0500
Organization: Mandeno Granville elect
References: 01-03-006
Keywords: assembler
Posted-Date: 04 Mar 2001 01:39:08 EST

Randall Hyde wrote:
>
<snip Summary>
> So here's my question: why can't we write an "optimizing assembler"
> that lets the programmer specify machine sequences and the assembler
> does the same kinds of "book keeping" that a HLL compiler would do.
> ...
> Of course, the real problem is "who would be willing to write such a
> thing?" (and maintain it.) But the idea seems interesting to me. Let
> the machine choose the best instruction organization given a sequence
> in machine code. Let the machine rearrange registers in instructions
> to make better use of them (and move memory accesses into registers,
> if needed). Let the machine eliminate dead code. Let the machine do
> code movement to improve performance.


  I am not sure exactly what you mean by 'Let the machine choose' ?


  Doing this ON-CHIP is probably too costly & risky in silicon, but the
pathway taken by the Crusoe Chip, and being picked up by AMD looks
very promising.


  They do a more extensive task of morphing, but the idea of an
'Optimse for Core' software layer would seem to meet your target.


  Transmeta must have solved the problem of 'morphing data tables by
mistake':-) but I have not seen reports of how they cope with the most
paranoid self modifying code often found in dongles ?


  Given the huge expense in silicon engineering to rack +20% in speed,
some smart software would seem an ideal answer, and would be readily
funded by the Chip makers, as it would allow their newest releases to
shine, and avoid that serious SW lag problem.


  I did see an interesting release from Transmeta claiming some ??%
improvement in their latest morphing Sw release.
  You can see scope here to 'spot and replace' some legacy code in
common operating systems, and improve the operation.


-jg


Post a followup to this message

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