Re: Optimizing in assembly language

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

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