|Optimizing in assembly language firstname.lastname@example.org (Randall Hyde) (2001-03-01)|
|Re: Optimizing in assembly language email@example.com (Jim Granville) (2001-03-04)|
|Re: Optimizing in assembly language firstname.lastname@example.org (Shankar Unni) (2001-03-04)|
|Re: Optimizing in assembly language email@example.com (T.Shackell) (2001-03-08)|
|Re: Optimizing in assembly language firstname.lastname@example.org (Jonathan Guthrie) (2001-03-08)|
|Re: Optimizing in assembly language email@example.com (Laurent Desnogues) (2001-03-08)|
|Re: Optimizing in assembly language firstname.lastname@example.org (Tzvetan Mikov) (2001-03-08)|
|Re: Optimizing in assembly language email@example.com (A Johnstone) (2001-03-08)|
|[12 later articles]|
|From:||Jim Granville <firstname.lastname@example.org>|
|Date:||4 Mar 2001 01:39:08 -0500|
|Organization:||Mandeno Granville elect|
|Posted-Date:||04 Mar 2001 01:39:08 EST|
Randall Hyde wrote:
> 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
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.
Return to the
Search the comp.compilers archives again.