mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: "mingo@elte.hu" <mingo@elte.hu>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>
Subject: RE: [PATCH v2] x86: modernize sync_bitops.h
Date: Wed, 21 Nov 2018 15:53:05 +0000	[thread overview]
Message-ID: <9dc88b57164e481184dfbb4b2079086e@AcuMS.aculab.com> (raw)
In-Reply-To: <5BF56EA502000078001FE90E@prv1-mh.provo.novell.com>



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 21 November 2018 14:42
> To: David Laight
> Cc: mingo@elte.hu; tglx@linutronix.de; Boris Ostrovsky; Juergen Gross; linux-kernel@vger.kernel.org;
> hpa@zytor.com
> Subject: RE: [PATCH v2] x86: modernize sync_bitops.h
> 
> >>> On 21.11.18 at 14:49, <David.Laight@ACULAB.COM> wrote:
> > From: Jan Beulich
> >> Sent: 21 November 2018 13:03
> >>
> >> >>> On 21.11.18 at 12:55, <David.Laight@ACULAB.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.
> 
> Excuse me? How about you look at this table from the SDM
> (format of course comes out better in the .pdf):
> 
> 0F AB /r BTS r/m16, r16 MR Valid Valid Store selected bit in CF flag and set.
> 0F AB /r BTS r/m32, r32 MR Valid Valid Store selected bit in CF flag and set.
> REX.W + 0F AB /r BTS r/m64, r64 MR Valid N.E. Store selected bit in CF flag and set.
> 0F BA /5 ib BTS r/m16, imm8 MI Valid Valid Store selected bit in CF flag and set.
> 0F BA /5 ib BTS r/m32, imm8 MI Valid Valid Store selected bit in CF flag and set.
> REX.W + 0F BA /5 ib BTS r/m64, imm8 MI Valid N.E. Store selected bit in CF flag and set.
> 
> Please read manuals yourself before making such statements.
> 
> > 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.
> 
> There is no form with %cl as operand. Instead there are forms with
> an immediate operand.

See also section 3.1.1.9 (in the copy of 325462.pdf I have):
(edited out references to the figures)

Bit(BitBase, BitOffset) — Returns the value of a bit within a bit string.
   The bit string is a sequence of bits in memory or a register. Bits are
   numbered from low-order to high-order within registers and within memory
   bytes. If the BitBase is a register, the BitOffset can be in the range 0
   to [15, 31, 63] depending on the mode and register size.

   If BitBase is a memory address, the BitOffset can range has different ranges
   depending on the operand size (see Table 3-2).

   The addressed bit is numbered (Offset MOD 8) within the byte at address
   (BitBase + (BitOffset DIV 8)) where DIV is signed division with rounding
   towards negative infinity and MOD returns a positive number.

Table 3-2. Range of Bit Positions Specified by Bit Offset Operands
Operand Size Immediate BitOffset   Register BitOffset
    16             0 to 15         2**15 to 2**15 − 1
    32             0 to 31         2**31 to 2**31 − 1
    64             0 to 63         2**63 to 2**63 − 1

For Bit test it says:

When accessing a bit in memory, the processor may access 4 bytes starting from
the memory address for a 32-bit operand size, using by the following relationship:
    Effective Address + (4 ∗ (BitOffset DIV 32))
Or, it may access 2 bytes starting from the memory address for a 16-bit operand, using this relationship:
    Effective Address + (2 ∗ (BitOffset DIV 16))
It may do so even when only a single byte needs to be accessed to reach the given bit.

(That is the text I remember being in the old docs, but I don't think it
used to refer to the address being aligned.
My 8086, 286 and 386 books are all at home.)

The other instructions (eg btc) say:

If the bit base operand specifies a memory location, the operand represents the
address of the byte in memory that contains the bit base (bit 0 of the specified byte)
of the bit string. The range of the bit position that can be
referenced by the offset operand depends on the operand size.

So the 'operand size' gives the size of the bit offset, not the size of
the memory cycle.

Maybe I'll run some instructions against a PCIe slave and monitor the TLPs.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2018-11-21 15:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25 10:24 [PATCH] " Jan Beulich
2018-06-26  7:18 ` Ingo Molnar
2018-06-26  7:26   ` Jan Beulich
     [not found] ` <5B30C2C302000000000FA99B@prv1-mh.provo.novell.com>
     [not found]   ` <5B30C2C302000078001FE5A0@prv1-mh.provo.novell.com>
2018-11-21 10:11     ` [PATCH v2] " Jan Beulich
2018-11-21 11:55       ` David Laight
2018-11-21 13:02         ` Jan Beulich
2018-11-21 13:49           ` David Laight
2018-11-21 14:41             ` Jan Beulich
2018-11-21 15:53               ` David Laight [this message]
2018-11-27 19:51                 ` Sean Christopherson
     [not found]     ` <5BF52F4D02000000001006ED@prv1-mh.provo.novell.com>
     [not found]       ` <5BF52F4D020000780022227E@prv1-mh.provo.novell.com>
2019-03-27 15:15         ` [PATCH v2 RESEND] " Jan Beulich
2019-04-10  8:47           ` [tip:x86/asm] x86/asm: Modernize sync_bitops.h tip-bot for Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9dc88b57164e481184dfbb4b2079086e@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®