|Using extra outputs of an instruction email@example.com (Dobes Vandermeer) (2002-03-09)|
|Re: Using extra outputs of an instruction firstname.lastname@example.org (2002-03-11)|
|Re: Using extra outputs of an instruction email@example.com (2002-03-17)|
|Re: Using extra outputs of an instruction firstname.lastname@example.org (Michael Meissner) (2002-03-21)|
|Re: Using extra outputs of an instruction email@example.com (David Chase) (2002-03-22)|
|Re: Using extra outputs of an instruction firstname.lastname@example.org (Bo Persson) (2002-03-24)|
|Date:||11 Mar 2002 02:18:21 -0500|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||11 Mar 2002 02:18:21 EST|
Dobes Vandermeer <email@example.com> schreibt:
>I initially realised the futility when I was entering the
>specification of Intel's XCHG operator. I looked at it and said,
>"this selector will only see a register move here; it has no reason to
>select XCHG over MOV."
IMO the XCHG instruction was designed to move register "variables"
into specific registers for following instructions, which expect
arguments in dedicated registers, without destroying the values which
previously resided in those dedicated registers. So the usage of XCHG
over MOV depends on the cost of saving and reloading the value in the
"other" register, and is subject to a more general optimization. XCHG
is useless without optimization!
Another case of multiple output instructions is DIV, which (usually)
produces both the quotient and remainder of the division. In former
times, when DIV was a time consuming operation, many compiler
libraries provided functions which returned both the quotient and
remainder at the same time, so that the optimization was left to the
programmer. But such constructs are not normally available in high
level programming languages, so that nowadays the programmer expects
the optimization be done by the compiler, when both results are used
in further computations.
I have no hints on how to handle such instructions in a compiler, I
only know how to handle them in a decompiler ;-)
[I always thought that XCHG was mostly there to do atomic lock updates.
Return to the
Search the comp.compilers archives again.