[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47f7dfd9b32f4425ac8466c8b0065c6e@AcuMS.aculab.com>
Date: Wed, 21 Nov 2018 13:49:26 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Jan Beulich' <JBeulich@...e.com>
CC: "mingo@...e.hu" <mingo@...e.hu>,
"tglx@...utronix.de" <tglx@...utronix.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
"Juergen Gross" <jgross@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hpa@...or.com" <hpa@...or.com>
Subject: RE: [PATCH v2] x86: modernize sync_bitops.h
From: Jan Beulich
> Sent: 21 November 2018 13:03
>
> >>> On 21.11.18 at 12:55, <David.Laight@...LAB.COM> wrote:
> > From: Jan Beulich
> >> Sent: 21 November 2018 10:11
> >>
> >> Add missing insn suffixes and use rmwcc.h just like was (more or less)
> >> recently done for bitops.h as well.
> >
> > Why? bts (etc) on memory don't really have an 'operand size'.
>
> Of course they do - depending on operand size they operate on
> 2-, 4-, or 8-byte quantities. When the second operand is a
> register, the suffix is redundant (but doesn't hurt), but when
> the second operand is an immediate, the assembler (in AT&T
> syntax) has no way of knowing what operand size you mean.
You need to RTFM.
Regardless of the 'operand size' the 'bit' instructions do a 32 bit aligned
32 bit wide read/modify/write cycle.
The 'operand size' does affect whether the bit number (which is signed)
comes from %cl (8 bits), %cx (16 bits), %rcx (32 bits) or (%ecx) 64 bits.
But that is implicit in the register name used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists