On 3/31/2014 1:41 AM, Andrew Haley wrote:
On 03/31/2014 05:44 AM, dw wrote:
So, after looking over this discussion, I have updated the text. This
time no undefined terms, while still conveying all the points I had in mind:
The "memory" clobber tells the compiler that the assembly code performs
On 03/31/2014 05:44 AM, dw wrote:
> So, after looking over this discussion, I have updated the text. This
> time no undefined terms, while still conveying all the points I had in mind:
>
> The "memory" clobber tells the compiler that the assembly code performs
> memory reads or writes to items o
So, after looking over this discussion, I have updated the text. This
time no undefined terms, while still conveying all the points I had in mind:
The "memory" clobber tells the compiler that the assembly code performs
memory reads or writes to items other than those listed in the input and
ou
On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
>> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
>
On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> >> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley
On Fri, Mar 28, 2014 at 03:03:11PM +, Andrew Haley wrote:
> On 03/28/2014 02:48 PM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 01:15:39PM +, Andrew Haley wrote:
> >> On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> >>> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley
On 03/28/2014 10:46 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
>> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
>>> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
On 03/28/2014 06:20 AM, dw wrote:
> Using this clobbe
On 28-Mar-14 01:46 PM, Hannes Frederic Sowa wrote:
On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
Ok, I see the problem. Maybe something like this by avoiding the term?
Using this clobber causes the compiler to flush all (modified)
registers being used to store values which gcc d
On Fri, Mar 28, 2014 at 09:41:41AM +, Andrew Haley wrote:
> On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> > On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> >> On 03/28/2014 06:20 AM, dw wrote:
> >>> Using this clobber causes the compiler to flush all (modified) registers
On 03/28/2014 09:30 AM, Hannes Frederic Sowa wrote:
> On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
>> On 03/28/2014 06:20 AM, dw wrote:
>>> Using this clobber causes the compiler to flush all (modified) registers
>>> being used to store memory-based values to memory before executi
On Fri, Mar 28, 2014 at 09:10:11AM +, Andrew Haley wrote:
> On 03/28/2014 06:20 AM, dw wrote:
> > Using this clobber causes the compiler to flush all (modified) registers
> > being used to store memory-based values to memory before executing the
> > @code{asm} statement.
>
> I don't know wha
On 03/28/2014 06:20 AM, dw wrote:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement.
I don't know what a "memory-based" value is. This phrase doesn't help
at all. In additio
dw writes:
> Using this clobber causes the compiler to flush all (modified) registers
> being used to store memory-based values to memory before executing the
> @code{asm} statement. Further, the compiler will not assume that any
> memory-based values read before the @code{asm} will remain unc
Looks great to me. Just noticed one small nit: in the extended asm
section, "=irm" isn't valid, since you can't assign to an immediate.
Doh! I probably copied this from the Input section. Good catch.
Also, in the section about clobbers:
It causes the compiler to flush all registers to
dw writes:
>> I think it really is general though. In:
>>> The same problem can occur if one output parameter (@var{a}) allows a
>>> register constraint, is updating the parameter value, and references an
>>> address while another output parameter (@var{b}) allows a memory
>>> constraint.
>
> Yep,
I think it really is general though. In:
The same problem can occur if one output parameter (@var{a}) allows a
register constraint, is updating the parameter value, and references an
address while another output parameter (@var{b}) allows a memory
constraint.
Yep, you're right. I have trimme
dw writes:
> On 3/25/2014 4:20 AM, Richard Sandiford wrote:
>> dw writes:
asm ("" : "=m" (*x), "=r" (y));
you have to assume that the address in %0 might use the same register as %1
>>> Ok, now I'm getting there. It helps that I've compiled some examples
>>> and can see what i
On 3/25/2014 4:20 AM, Richard Sandiford wrote:
dw writes:
asm ("" : "=m" (*x), "=r" (y));
you have to assume that the address in %0 might use the same register as %1
Ok, now I'm getting there. It helps that I've compiled some examples
and can see what is happening. This one is subtle.
dw writes:
>>asm ("" : "=m" (*x), "=r" (y));
>>
>> you have to assume that the address in %0 might use the same register as %1
>
> Ok, now I'm getting there. It helps that I've compiled some examples
> and can see what is happening. This one is subtle. I'm going to have
> to go back and r
Sorry for the slow response.
Thanks for getting back to me. I was pretty sure I didn't have this all
quite right yet.
asm ("" : "=m" (*x), "=r" (y));
you have to assume that the address in %0 might use the same register as %1
Ok, now I'm getting there. It helps that I've compiled s
Sorry for the slow response.
dw writes:
> On 3/3/2014 3:36 AM, Richard Sandiford wrote:
>> Well, like you say, things can be moved across branches. So, although
>> this is a very artificial example:
>>
>> asm ("x");
>> asm ("y");
>>
>> could become:
>>
>> goto bar;
>>
>> foo:
>
On 3/21/2014 2:57 AM, James Greenhalgh wrote:
On Thu, Feb 27, 2014 at 11:07:21AM +, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing
On Thu, Feb 27, 2014 at 11:07:21AM +, Andrew Haley wrote:
> Over the years there has been a great deal of traffic on these lists
> caused by misunderstandings of GCC's inline assembler. That's partly
> because it's inherently tricky, but the existing documentation needs
> to be improved.
>
>
On 3/3/2014 3:36 AM, Richard Sandiford wrote:
dw writes:
On 2/27/2014 11:32 PM, Richard Sandiford wrote:
dw writes:
On 2/27/2014 4:11 AM, Richard Sandiford wrote:
Andrew Haley writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC'
dw writes:
> On 2/27/2014 11:32 PM, Richard Sandiford wrote:
>> dw writes:
>>> On 2/27/2014 4:11 AM, Richard Sandiford wrote:
Andrew Haley writes:
> Over the years there has been a great deal of traffic on these lists
> caused by misunderstandings of GCC's inline assembler. That's
On 2/27/2014 8:12 PM, Andi Kleen wrote:
dw writes:
What would you say to something like this:
"Since GCC does not parse the asm, it has no visibility of any static
variables or functions it references. This may result in those
symbols getting discarded by GCC as unused. To avoid this proble
dw writes:
> On 2/27/2014 4:11 AM, Richard Sandiford wrote:
>> Andrew Haley writes:
>>> Over the years there has been a great deal of traffic on these lists
>>> caused by misunderstandings of GCC's inline assembler. That's partly
>>> because it's inherently tricky, but the existing documentation
dw writes:
>
> What would you say to something like this:
>
> "Since GCC does not parse the asm, it has no visibility of any static
> variables or functions it references. This may result in those
> symbols getting discarded by GCC as unused. To avoid this problem,
> list the symbols as inputs o
On 2/27/2014 9:35 AM, Andi Kleen wrote:
Andrew Haley writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw has
On 2/27/2014 4:22 AM, Kyrill Tkachov wrote:
On 27/02/14 11:07, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to b
On 2/27/2014 4:11 AM, Richard Sandiford wrote:
Andrew Haley writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
d
Andrew Haley writes:
> Over the years there has been a great deal of traffic on these lists
> caused by misunderstandings of GCC's inline assembler. That's partly
> because it's inherently tricky, but the existing documentation needs
> to be improved.
>
> dw has done a fairly thorough reworking
On 27/02/14 11:07, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw has done a fairly thorough re
Andrew Haley writes:
> Over the years there has been a great deal of traffic on these lists
> caused by misunderstandings of GCC's inline assembler. That's partly
> because it's inherently tricky, but the existing documentation needs
> to be improved.
>
> dw has done a fairly thorough reworking
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw has done a fairly thorough reworking of
the documentation. I've helpe
35 matches
Mail list logo
