Re: Patch Review: i386 asm cleanups in the kernel
On 14-Dec-01 David Xu wrote: > I persist with adding "cc", because it does not hurt anything. It doesn't do anything either except add repo bloat and obfuscate the code a bit more. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
I persist with adding "cc", because it does not hurt anything.
--
David Xu
John Baldwin wrote:
>On 13-Dec-01 Bruce Evans wrote:
>
>>>--- i386/i386/identcpu.c 30 Nov 2001 11:57:23 - 1.96
>>>+++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -
>>>@@ -115,10 +115,11 @@
>>> static void
>>> do_cpuid(u_int ax, u_int *p)
>>> {
>>>+
>>>+p[0] = ax;
>>> __asm __volatile(
>>> "cpuid"
>>>-: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>>>-: "0" (ax)
>>>+: "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>>> );
>>> }
>>>
>>"0" here was bogus. Just replace it by "a".
>>
>
>So use "a" twice and gcc will get that right?
>
>>>-: "=a" (low), "=d" (high) \
>>>-: "0" (low), "1" (high) \
>>>-: "cx", "bx")
>>>+: "+a" (low), "+d" (high) \
>>>+: : "ecx", "ebx")
>>>
>>Weren't the register names in the clobber list the normal ones?
>>
>
>I was just being pedantic since we aren't just clobbering the low words of the
>registers.
>
>
>>>@@ -938,7 +935,7 @@
>>> "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t"
>>> "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t"
>>> "movl 12(%0),%%eax ; adcl %%eax,12(%0)"
>>>-::"r" (c):"ax");
>>>+: :"r" (c):"eax", "memory");
>>> }
>>>
>>> static void
>>>
>>This should use output operands c[0]..c[3], not a general "memory" clobber.
>>
>
>Ok.
>
>>>[... more suboptimal "memory" clobbers]
>>>
>
>I changed the simple ones, but not the harder ones. (gcc doesn't like having
>more than 10 operands, even if they are memory or immediates)
>
>>I wouldn't trust all the little changes to math_emulate.c without runtime
>>testing. It won't be tested by using it in normal operation.
>>
>
>Ok. I won't commit it until it is tested.
>
>>>Index: i386/include/bus_pc98.h
>>>===
>>>RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v
>>>retrieving revision 1.19
>>>diff -u -r1.19 bus_pc98.h
>>>--- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 - 1.19
>>>+++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -
>>>@@ -203,11 +203,10 @@
>>> \
>>> __asm __volatile("call *%2" \
>>> :"=a" (result), \
>>>- "=d" (offset) \
>>>+ "+d" (offset) \
>>> :"o" (bsh->bsh_bam.bs_read_##BWN), \
>>>- "b" (bsh), \
>>>- "1" (offset) \
>>>-); \
>>>+ "b" (bsh) \
>>>+:"ecx","memory"); \
>>> \
>>> return result; \
>>> }
>>>
>>It's surprising that the missing "ecx" in lots of clobber lists in this
>>file didn't cause problems.
>>
>
>It depends on what the functions do. If they are written in asm, they might be
>preserving temporary registers rather than trashing them. I was just changing
>the clobbers to assume that only call-safe registers were preserved.
>
>>>-__asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask));
>>>+__asm __volatile("bsfl %0,%0" : "+r" (result));
>>> return (result);
>>> }
>>>
>>"0" here was bogus, except we abuse the same operand for input and output.
>>I checked that gcc does the right thing (reuse the input register for
>>output if the input operand becomes dead) with a non-hand-optimized version:
>>
>> __asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask));
>> ...
>> main() { return bsfl(23); }
>>
>>"rm" (mask) works too.
>>
>
>Ok, that's simpler then.
>
>>The other changes seem to be OK. I checked about 1/4 of them.
>>
>
>Ok, well, I've updated the patch at the same location.
>
>>Bruce
>>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On 13-Dec-01 John Baldwin wrote:
>>> static void
>>> do_cpuid(u_int ax, u_int *p)
>>> {
>>> +
>>> +p[0] = ax;
>>> __asm __volatile(
>>> "cpuid"
>>> -: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>>> -: "0" (ax)
>>> +: "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>>> );
>>> }
>>>
>>
>> "0" here was bogus. Just replace it by "a".
>
> So use "a" twice and gcc will get that right?
gcc30 chokes on it:
../../../i386/i386/identcpu.c: In function `do_cpuid':
../../../i386/i386/identcpu.c:119: Can't find a register in class `AREG' while
reloading `asm'.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On Thu, Dec 06, 2001 at 08:40:29PM +1100, Bruce Evans wrote: >On Wed, 5 Dec 2001, John Baldwin wrote: > >> On 05-Dec-01 Bruce Evans wrote: >> >> - Add missing "cc" clobbers in constraints >> > >> > Does this have any effect (for i386's) except to create a lot of clutter >> > Even i386.md doesn't use it. gcc.info says: >> > ... >> > None of i386.md, alpha.md or sparc.md do this. i386's and alphas have a >> > cc0 register, but it is only mentioned for instructsions whose main (only?) >> > effect is to to set the condition codes. >> >> Hmm, so how does one clobber "eflags" if "cc" isn't "eflags"? > >Neither seems to be in gcc/config/i386/i386.h. I think "cc" is generic, so >using it in clobber lists is not wrong. To quote the "Extended Asm" section of the GCC info file: " If your assembler instruction can alter the condition code register, add `cc' to the list of clobbered registers. GNU CC on some machines represents the condition codes as a specific hardware register; `cc' serves to name this register. On other machines, the condition code is handled differently, and specifying `cc' has no effect. But it is valid no matter what the machine." >> Look at PR >> gnu/32365 which seems to indicate that "cc" does, in fact, represent "eflags" >> in the clobber list. My understanding (from the above quote) is that "cc" is a generic virtual register used to represent a processor's condition codes - independent of how the processor actually implements conditions. "eflags" is the physical i386 register containing the condition codes (amongst other things). >That gives a hint about where to look for the clobbering conventions. From >gcc/config/i386/i386.c: ... >Application asms are apparently in the "All else" set. This appears to come down to a case of the generic documentation requiring "cc" clobbers, whereas the current implementation on the i386 doesn't. >The bug in the PR could probably be fixed without updating this function >by using leal instead of addl to adjust the stack. Good point. There seem to be 3 options: 1a) Modify notice_update_cc() to recognize the RTL associated with mov[sdx]f_push and clobber the condition codes in that case. This is the approach I suggested in the PR. 1b) Modify the mov[sdx]f_push templates in i386.md to do a CC_STATUS_INIT. I have implemented this and it seems to work. I'll post it into the PR at some stage. 2) Modify the mov[sdx]f_push templates in i386.md to use leal ISO subl. This is probably the best option since it will preserve the condition code. Unfortunately, I'm not sure how to define an RTX for "-4(%esp)", a quick rummage suggests adj_offsettable_operand(), but that doesn't allow negative offsets. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On 13-Dec-01 Bruce Evans wrote:
>> --- i386/i386/identcpu.c 30 Nov 2001 11:57:23 - 1.96
>> +++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -
>> @@ -115,10 +115,11 @@
>> static void
>> do_cpuid(u_int ax, u_int *p)
>> {
>> +
>> +p[0] = ax;
>> __asm __volatile(
>> "cpuid"
>> -: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>> -: "0" (ax)
>> +: "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
>> );
>> }
>>
>
> "0" here was bogus. Just replace it by "a".
So use "a" twice and gcc will get that right?
>> -: "=a" (low), "=d" (high) \
>> -: "0" (low), "1" (high) \
>> -: "cx", "bx")
>> +: "+a" (low), "+d" (high) \
>> +: : "ecx", "ebx")
>
> Weren't the register names in the clobber list the normal ones?
I was just being pedantic since we aren't just clobbering the low words of the
registers.
>> @@ -938,7 +935,7 @@
>> "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t"
>> "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t"
>> "movl 12(%0),%%eax ; adcl %%eax,12(%0)"
>> -::"r" (c):"ax");
>> +: :"r" (c):"eax", "memory");
>> }
>>
>> static void
>
> This should use output operands c[0]..c[3], not a general "memory" clobber.
Ok.
>> [... more suboptimal "memory" clobbers]
I changed the simple ones, but not the harder ones. (gcc doesn't like having
more than 10 operands, even if they are memory or immediates)
> I wouldn't trust all the little changes to math_emulate.c without runtime
> testing. It won't be tested by using it in normal operation.
Ok. I won't commit it until it is tested.
>> Index: i386/include/bus_pc98.h
>> ===
>> RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v
>> retrieving revision 1.19
>> diff -u -r1.19 bus_pc98.h
>> --- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 - 1.19
>> +++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -
>> @@ -203,11 +203,10 @@
>> \
>> __asm __volatile("call *%2" \
>> :"=a" (result), \
>> - "=d" (offset) \
>> + "+d" (offset) \
>> :"o" (bsh->bsh_bam.bs_read_##BWN), \
>> - "b" (bsh), \
>> - "1" (offset) \
>> -); \
>> + "b" (bsh) \
>> +:"ecx","memory"); \
>> \
>> return result; \
>> }
>
> It's surprising that the missing "ecx" in lots of clobber lists in this
> file didn't cause problems.
It depends on what the functions do. If they are written in asm, they might be
preserving temporary registers rather than trashing them. I was just changing
the clobbers to assume that only call-safe registers were preserved.
>> -__asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask));
>> +__asm __volatile("bsfl %0,%0" : "+r" (result));
>> return (result);
>> }
>
> "0" here was bogus, except we abuse the same operand for input and output.
> I checked that gcc does the right thing (reuse the input register for
> output if the input operand becomes dead) with a non-hand-optimized version:
>
> __asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask));
> ...
> main() { return bsfl(23); }
>
> "rm" (mask) works too.
Ok, that's simpler then.
> The other changes seem to be OK. I checked about 1/4 of them.
Ok, well, I've updated the patch at the same location.
> Bruce
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On Tue, 11 Dec 2001, John Baldwin wrote:
> Ok, I've axed all the "cc" clobbers from the patch now. Any objections to it
> now? It's still at ~jhb/patches/i386_asm.patch.
Review of what I can see: the URL still appears to be well formed ;-). But
it didn't seem to work, so I scp'ed the file.
> Index: i386/i386/identcpu.c
> ===
> RCS file: /usr/cvs/src/sys/i386/i386/identcpu.c,v
> retrieving revision 1.96
> diff -u -r1.96 identcpu.c
> --- i386/i386/identcpu.c 30 Nov 2001 11:57:23 - 1.96
> +++ i386/i386/identcpu.c 6 Dec 2001 07:58:25 -
> @@ -115,10 +115,11 @@
> static void
> do_cpuid(u_int ax, u_int *p)
> {
> +
> + p[0] = ax;
> __asm __volatile(
> "cpuid"
> - : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
> - : "0" (ax)
> + : "+a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
> );
> }
>
"0" here was bogus. Just replace it by "a".
> Index: i386/i386/math_emulate.c
> ===
> RCS file: /usr/cvs/src/sys/i386/i386/math_emulate.c,v
> retrieving revision 1.40
> diff -u -r1.40 math_emulate.c
> --- i386/i386/math_emulate.c 28 Nov 2001 01:42:16 - 1.40
> +++ i386/i386/math_emulate.c 7 Dec 2001 19:07:16 -
> ...
> @@ -771,14 +770,13 @@
> "addl %0,%0 ; adcl %1,%1\n\t" \
> "addl %0,%0 ; adcl %1,%1\n\t" \
> "addl %%ecx,%0 ; adcl %%ebx,%1" \
> - : "=a" (low), "=d" (high) \
> - : "0" (low), "1" (high) \
> - : "cx", "bx")
> + : "+a" (low), "+d" (high) \
> + : : "ecx", "ebx")
Weren't the register names in the clobber list the normal ones?
> @@ -938,7 +935,7 @@
> "movl 4(%0),%%eax ; adcl %%eax,4(%0)\n\t"
> "movl 8(%0),%%eax ; adcl %%eax,8(%0)\n\t"
> "movl 12(%0),%%eax ; adcl %%eax,12(%0)"
> - ::"r" (c):"ax");
> + : :"r" (c):"eax", "memory");
> }
>
> static void
This should use output operands c[0]..c[3], not a general "memory" clobber.
> [... more suboptimal "memory" clobbers]
I wouldn't trust all the little changes to math_emulate.c without runtime
testing. It won't be tested by using it in normal operation.
> Index: i386/include/bus_pc98.h
> ===
> RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v
> retrieving revision 1.19
> diff -u -r1.19 bus_pc98.h
> --- i386/include/bus_pc98.h 7 Oct 2001 10:04:18 - 1.19
> +++ i386/include/bus_pc98.h 7 Dec 2001 19:10:37 -
> @@ -203,11 +203,10 @@
> \
> __asm __volatile("call *%2" \
> :"=a" (result), \
> - "=d" (offset) \
> + "+d" (offset) \
> :"o" (bsh->bsh_bam.bs_read_##BWN), \
> - "b" (bsh), \
> - "1" (offset) \
> - ); \
> + "b" (bsh) \
> + :"ecx","memory"); \
> \
> return result; \
> }
It's surprising that the missing "ecx" in lots of clobber lists in this
file didn't cause problems.
> Index: i386/include/cpufunc.h
> ===
> RCS file: /usr/cvs/src/sys/i386/include/cpufunc.h,v
> retrieving revision 1.105
> diff -u -r1.105 cpufunc.h
> --- i386/include/cpufunc.h28 Jun 2001 02:08:13 - 1.105
> +++ i386/include/cpufunc.h7 Dec 2001 19:11:47 -
> @@ -66,18 +66,18 @@
> static __inline u_int
> bsfl(u_int mask)
> {
> - u_int result;
> + u_int result = mask;
Style bug: initialization in declaration.
>
> - __asm __volatile("bsfl %0,%0" : "=r" (result) : "0" (mask));
> + __asm __volatile("bsfl %0,%0" : "+r" (result));
> return (result);
> }
"0" here was bogus, except we abuse the same operand for input and output.
I checked that gcc does the right thing (reuse the input register for
output if the input operand becomes dead) with a non-hand-optimized version:
__asm __volatile("bsfl %1,%0" : "=r" (result) : "r" (mask));
...
main() { return bsfl(23); }
"rm" (mask) works too.
>
> static __inline u_int
> bsrl(u_int mask)
> {
> - u_int result;
> + u_int result = mask;
>
> - __asm __volatile("bsrl
Re: Patch Review: i386 asm cleanups in the kernel
On 06-Dec-01 Bruce Evans wrote: > That gives a hint about where to look for the clobbering conventions. From > gcc/config/i386/i386.c: > > ! /* Set the cc_status for the results of an insn whose pattern is EXP. > !On the 80386, we assume that only test and compare insns, as well > !as SI, HI, & DI mode ADD, SUB, NEG, AND, IOR, XOR, BSF, ASHIFT, > !ASHIFTRT, and LSHIFTRT instructions set the condition codes usefully. > !Also, we assume that jumps, moves and sCOND don't affect the condition > !codes. All else clobbers the condition codes, by assumption. > > ! > !We assume that ALL integer add, minus, etc. instructions effect the > !condition codes. This MUST be consistent with i386.md. > ! > !We don't record any float test or compare - the redundant test & > !compare check in final.c does not handle stack-like regs correctly. */ > ! > ! void > ! notice_update_cc (exp) > ! rtx exp; > > Application asms are apparently in the "All else" set. Ok, I've axed all the "cc" clobbers from the patch now. Any objections to it now? It's still at ~jhb/patches/i386_asm.patch. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On Wed, 5 Dec 2001, John Baldwin wrote: > On 05-Dec-01 Bruce Evans wrote: > >> - Add missing "cc" clobbers in constraints > > > > Does this have any effect (for i386's) except to create a lot of clutter > > Even i386.md doesn't use it. gcc.info says: > > ... > > None of i386.md, alpha.md or sparc.md do this. i386's and alphas have a > > cc0 register, but it is only mentioned for instructsions whose main (only?) > > effect is to to set the condition codes. > > Hmm, so how does one clobber "eflags" if "cc" isn't "eflags"? Neither seems to be in gcc/config/i386/i386.h. I think "cc" is generic, so using it in clobber lists is not wrong. > Look at PR > gnu/32365 which seems to indicate that "cc" does, in fact, represent "eflags" > in the clobber list. That gives a hint about where to look for the clobbering conventions. From gcc/config/i386/i386.c: ! /* Set the cc_status for the results of an insn whose pattern is EXP. !On the 80386, we assume that only test and compare insns, as well !as SI, HI, & DI mode ADD, SUB, NEG, AND, IOR, XOR, BSF, ASHIFT, !ASHIFTRT, and LSHIFTRT instructions set the condition codes usefully. !Also, we assume that jumps, moves and sCOND don't affect the condition !codes. All else clobbers the condition codes, by assumption. ! !We assume that ALL integer add, minus, etc. instructions effect the !condition codes. This MUST be consistent with i386.md. ! !We don't record any float test or compare - the redundant test & !compare check in final.c does not handle stack-like regs correctly. */ ! ! void ! notice_update_cc (exp) ! rtx exp; Application asms are apparently in the "All else" set. The bug in the PR could probably be fixed without updating this function by using leal instead of addl to adjust the stack. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On Wed, Dec 05, 2001 at 02:36:49PM -0800, John Baldwin wrote: > The patch is at http://www.FreeBSD.org/~jhb/patches/i386_asm.patch. Mostly it > does the following: Can you compile some files with gcc30 and see if you get any new/different warnings about this. Also look at the i386.md file for both Gcc 3.0 and 3.1 (I can email them to you). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On 05-Dec-01 Bruce Evans wrote: >> - Add missing "cc" clobbers in constraints > > Does this have any effect (for i386's) except to create a lot of clutter > Even i386.md doesn't use it. gcc.info says: > > !If your assembler instruction can alter the condition code register, > ! add `cc' to the list of clobbered registers. GNU CC on some machines > ! represents the condition codes as a specific hardware register; `cc' > ! serves to name this register. On other machines, the condition code is > ! handled differently, and specifying `cc' has no effect. But it is > ! valid no matter what the machine. > ! > ! ... > !Here we will concern ourselves with determining the effect of an > ! insn on the condition code and will limit ourselves to the following > ! possible effects: The condition code can be set unpredictably > ! (clobbered), not be changed, be set to agree with the results of the > ! operation, or only changed if the item previously set into the > ! condition code has been modified. > ! > !Here is part of a sample `md' file for such a machine: > ! > ! (define_attr "type" "load,store,arith,fp,branch" (const_string > "arith")) > ! > ! (define_attr "cc" "clobber,unchanged,set,change0" > > None of i386.md, alpha.md or sparc.md do this. i386's and alphas have a > cc0 register, but it is only mentioned for instructsions whose main (only?) > effect is to to set the condition codes. Hmm, so how does one clobber "eflags" if "cc" isn't "eflags"? Look at PR gnu/32365 which seems to indicate that "cc" does, in fact, represent "eflags" in the clobber list. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch Review: i386 asm cleanups in the kernel
On Wed, 5 Dec 2001, John Baldwin wrote: Review of what I can see and quote easily. > The patch is at http://www.FreeBSD.org/~jhb/patches/i386_asm.patch. Mostly it > does the following: This URL appears to be well formed ;-). > - Add missing "cc" clobbers in constraints Does this have any effect (for i386's) except to create a lot of clutter Even i386.md doesn't use it. gcc.info says: !If your assembler instruction can alter the condition code register, ! add `cc' to the list of clobbered registers. GNU CC on some machines ! represents the condition codes as a specific hardware register; `cc' ! serves to name this register. On other machines, the condition code is ! handled differently, and specifying `cc' has no effect. But it is ! valid no matter what the machine. ! ! ... !Here we will concern ourselves with determining the effect of an ! insn on the condition code and will limit ourselves to the following ! possible effects: The condition code can be set unpredictably ! (clobbered), not be changed, be set to agree with the results of the ! operation, or only changed if the item previously set into the ! condition code has been modified. ! !Here is part of a sample `md' file for such a machine: ! ! (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) ! ! (define_attr "cc" "clobber,unchanged,set,change0" None of i386.md, alpha.md or sparc.md do this. i386's and alphas have a cc0 register, but it is only mentioned for instructsions whose main (only?) effect is to to set the condition codes. > - Use the "+" modifier for output operands rather than using "0", "1", etc. > to list operands in both input and output sections. > - Fix the atomic operations to accept the contraints type on v so we can use > "iq" rather than "ir" for char operations (this last came from Peter Jeremy > and bde). OK. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch Review: i386 asm cleanups in the kernel
The patch is at http://www.FreeBSD.org/~jhb/patches/i386_asm.patch. Mostly it does the following: - Add missing "cc" clobbers in constraints - Use the "+" modifier for output operands rather than using "0", "1", etc. to list operands in both input and output sections. - Fix the atomic operations to accept the contraints type on v so we can use "iq" rather than "ir" for char operations (this last came from Peter Jeremy and bde). I'm running it here on my laptop w/o problems and would like to commit it in a day or so. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
