inline asm semantics: output constraint width smaller than input

Even in the 64-bit-integer on 32-bit-CPU case, you still end up with
the lower 32-bits in a standard integer GPR, and it's trivial to just
ignore the "upper" register. You also would not need to do any kind
of bit-shift, so long as your inline assembly initializes both GPRs
and puts the halves of the result where they belong.

Cheers,
Kyle Moffett

Kyle Moffett wrote:

Even in the 64-bit-integer on 32-bit-CPU case, you still end up with
the lower 32-bits in a standard integer GPR, and it's trivial to just
ignore the "upper" register. You also would not need to do any kind
of bit-shift, so long as your inline assembly initializes both GPRs
and puts the halves of the result where they belong.

In this case, we're talking about what happens when the assembly takes a
64-bit input operand in the same register as a 32-bit output operand
(with a "0" constraint.) Is the output operand the same register number
as the high register or the low register? On an LE machine the answer
is trivial and obvious -- the low register; on a BE machine both
interpretations are possible (I actually suspect gcc will assign the
high register, just based on how gcc internals work in this case.)

  -hpa

On a BE 32-bit machine, the "output register" technically ought to be
"64-bit" anyways, since it's constrained to be the same as the 64-bit
"input register". That means that you ought to make sure to set
*both* output registers appropriately, one of them being 0 and the
other being the 32-bit number. I think that's the only answer that
actually makes any sense from a holistic code-generation sense. So it
seems we are in violent agreement :-D.

Cheers,
Kyle Moffett

Kyle Moffett wrote:

On a BE 32-bit machine, the "output register" technically ought to be
"64-bit" anyways, since it's constrained to be the same as the 64-bit
"input register". That means that you ought to make sure to set
*both* output registers appropriately, one of them being 0 and the
other being the 32-bit number. I think that's the only answer that
actually makes any sense from a holistic code-generation sense. So it
seems we are in violent agreement :-D.

No.

This is wrong on two accounts.

First of all, THERE ARE NO "TWO OUTPUT REGISTERS". Period. There is only one. The question is: which of the two *input* registers does it correspond to?

Second of all, "making sense from a holistic code-generation sense" doesn't apply here. This is about mimicing a gcc construct, regardless of which amount of sense it makes. Therefore, the only thing that actually makes sense is to mimic gcc behavior, no matter how stupid it happens to be.

  -hpa