| View previous topic :: View next topic |
| Author |
Message |
Bob Martin
Guest
|
 Posted: Wed Nov 12, 2008 7:04 pm Post subject: Re: Compiler error with Inline assembly |
 |
|
in 5317 20081111 195342 Timothy Baldwin <T.E.Baldwin99@members.leeds.ac.uk> wrote:
| Quote: | In message <yw1xskpzdyfo.fsf@thrashbarg.mansr.com>, Måns Rullgård
mans@mansr.com> wrote:
Sorry, it should be more like this:
void mul128(int64_t a, int64_t b, int64_t c[2])
{
__asm__ (
"imulq %1 \n\t"
"mov %rax, (%2) \n\t"
"mov %rdx, 0x8(%2) \n\t"
:: "a"(a), "g"(b), "r"(c) : "memory");
}
Still broken, it trashes %rax and %rdx.
The memory clobber is overkill, if you specify memory output operands gcc
will do the right thing. Better still leave the storing into the array to
C/C++ code so that the compiler can optimise it away.
|
Are you the Tim Baldwin of T editor fame? |
|
| |
|
 Back to top |
Timothy Baldwin
Guest
|
| Posted: Thu Nov 13, 2008 2:25 am Post subject: Re: Compiler error with Inline assembly |
|
|
In message <87myg5uu43.fsf@fever.mssgmbh.com>, Rainer Weikusat
<rweikusat@mssgmbh.com> wrote:
| Quote: | If doing so does not result in a dysfunctional binary, an even better
option would be to not write it in the first place.
|
Then how would you get the result out of the function? I was refer to the
act of storing the result into an array. The same argument applies to using
a struct, or separate pointers.
void mul128(int64_t a, int64_t b, int64_t c[2])
{
__asm__ (
"imulq %3"
: "=a"(c[0]), "=d"(c[1]) : "a"(a), "g"(b));
}
is much simpler, and later in the same file:
int64_t test() {
int64_t c[2];
mul128(a, b, c);
return c[1];
}
compiles to:
movq a(%rip), %rax
imulq b(%rip)
movq %rdx, %rax
ret
Furthermore a store to memory can not occur before a load from the same
location earlier in the program, which means in a loop which uses the same
array on each iteration the multiplies will execute consecutively rather
than concurrently. |
|
| |
|
| Back to top |
Rainer Weikusat
Guest
|
| Posted: Thu Nov 13, 2008 8:36 am Post subject: Re: Compiler error with Inline assembly |
|
|
Timothy Baldwin <T.E.Baldwin99@members.leeds.ac.uk> writes:
| Quote: | In message <87myg5uu43.fsf@fever.mssgmbh.com>, Rainer Weikusat
rweikusat@mssgmbh.com> wrote:
If doing so does not result in a dysfunctional binary, an even better
option would be to not write it in the first place.
|
Who is supposed to still understand that?
| Quote: | Then how would you get the result out of the function? I was refer to the
act of storing the result into an array. The same argument applies to using
a struct, or separate pointers.
void mul128(int64_t a, int64_t b, int64_t c[2])
{
__asm__ (
"imulq %3"
: "=a"(c[0]), "=d"(c[1]) : "a"(a), "g"(b));
}
is much simpler,
|
Its horizontal axis is larger than its vertical axis.
| Quote: | and later in the same file:
int64_t test() {
int64_t c[2];
mul128(a, b, c);
return c[1];
}
compiles to:
movq a(%rip), %rax
imulq b(%rip)
movq %rdx, %rax
ret
|
And taking into account that for THIS example, the array is completely
useless, there is no reason to use one to begin with. Which implies
that a more generally useful subroutine would return the value instead
of storing it in an output argument. This can be taken one step
further by also removing the load from the array for the input
argument, but passing a value instead. So, either the OP used the
array because he was confused. Then he should change that. Or because
there was a reason for using the array. Then 'use of an array' cannot
just be 'eliminated'.
The question inhowfar C code with undefined behaviour is useful for
demonstrating anything would still need to be answered, too.
| Quote: | Furthermore a store to memory can not occur before a load from the same
location earlier in the program, which means in a loop which uses the same
array on each iteration the multiplies will execute consecutively rather
than concurrently.
|
Inherently sequential operations (like using the result of a
multiplication for another multiplication) cannot be executed in
parallell. Regarding the array, the remark above applies. |
|
| |
|
| Back to top |
|
