Date: Tue, 05 Feb 2002 07:18:54 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Michal Mertl <mime@traveller.cz> Cc: audit@freebsd.org, jhb@freebsd.org Subject: Re: request for review: i386 64bit atomic patch Message-ID: <20020205071853.H72285@gsmx07.alcatel.com.au> In-Reply-To: <Pine.BSF.4.41.0202041221370.14840-100000@prg.traveller.cz>; from mime@traveller.cz on Mon, Feb 04, 2002 at 12:24:44PM %2B0100 References: <Pine.BSF.4.41.0202041221370.14840-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Feb-04 12:24:44 +0100, Michal Mertl <mime@traveller.cz> wrote: >+ " setz %%al ; " >+ " movzbl %%al,%0 ; " "%%al" could alternatively be written as "%b0" (From i386.md: 'b' => print the QImode name of the register for the indicated operand). >+ "#atomic_cmpset_64" >+ : "=a" (res), /* 0 */ The above change means that the "=a" could safely become "=q", which would allow gcc the freedom to pick something other than %eax. As a straight function, this doesn't help, but it may help for an inline. >+ : "a" ((u_long)exp), >+ "d" ((u_long)((u_long *)&exp)[1]), >+ "b" ((u_long)src), >+ "c" ((u_long)((u_long *)&src)[1]) I'd change these "u_long"s to "u_int32_t" or "u_register_t". This will stop the code breaking on bde's "long has 64 bits" test system. You might like to compare the code for "(u_long)((u_long *)&exp)[1]" with "(u_long)(exp >> 32)". >Thank Peter and John for your advices. What do you think now? Can someone >commit it? I don't see anything obviously wrong. Have you tested it with both gcc 2.95.1 and 3.x at various different optimisations? Constraint incompatibilities cause enough problems that we don't want to add any more. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020205071853.H72285>