All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Denys Vlasenko' <dvlasenk@redhat.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"brgerst@gmail.com" <brgerst@gmail.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"luto@kernel.org" <luto@kernel.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-tip-commits@vger.kernel.org" 
	<linux-tip-commits@vger.kernel.org>
Subject: RE: [tip:x86/asm] x86/entry/64: Add two more instruction suffixes
Date: Tue, 3 Jul 2018 12:25:18 +0000	[thread overview]
Message-ID: <4420eda360c240488f7ce38fd8baa778@AcuMS.aculab.com> (raw)
In-Reply-To: <68107758-8018-d8d5-dcfd-270bb64113eb@redhat.com>

From: Denys Vlasenko
> Sent: 03 July 2018 12:59
> 
> On 07/03/2018 10:46 AM, David Laight wrote:
> > From: Jan Beulich
> >> Sent: 03 July 2018 09:36
> > ...
> >> As said there, omitting suffixes from instructions in AT&T mode is bad
> >> practice when operand size cannot be determined by the assembler from
> >> register operands, and is likely going to be warned about by upstream
> >> gas in the future (mine does already).
> > ...
> >> -	bt	$9, EFLAGS(%rsp)		/* interrupts off? */
> >> +	btl	$9, EFLAGS(%rsp)		/* interrupts off? */
> >
> > Hmmm....
> > Does the operand size make any difference at all for the bit instructions?
> > I'm pretty sure that the cpus (386 onwards) have always done aligned 32bit
> > transfers (the docs never actually said aligned).
> > I can't remember whether 64bit mode allows immediates above 31.
> 
> Immediates up to 63 are allowed in 64 bit mode (IOW: for REX-prefixed form)
> (run-tested).
> 
> Keep in mind that this instruction is "special" with register bit offset:
> 
> Register/memory form (BT REG,[MEM]) does not limit or mask the value of bit offset
> in REG, the instruction uses bit REG%8 in byte at address [MEM+REG/8].
> 
> This works correctly even for negative values: REG = -1 will access
> the most significant bit in the byte immediately before MEM.
> 
> Thus, for accesses of standard RAM locations (not memory-mapped IO and such),
> the "operand size" concept for this instruction (and BTC, BTR, BTS)
> does not make much sense: it accesses one bit. The width of actual memory
> access is irrelevant.
> 
> I'd say assembler should just use the "natural" width for current mode
> (16 or 32-bit), and warn when code tries to use immediate operand which
> will be truncated and thus needs a wider operand size.
...


Indeed.

Truncating the immediate value really ought to be an error.
In 64bit mode the 64bit form should be used for immediates [32..63).
The 16bit form could safely be selected for immediates [0..15).

Requiring the width suffix is just stupid.

	David



      reply	other threads:[~2018-07-03 12:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02 10:47 [PATCH] x86/entry/64: add two more instruction suffixes Jan Beulich
2018-07-03  8:35 ` [tip:x86/asm] x86/entry/64: Add " tip-bot for Jan Beulich
2018-07-03  8:46   ` David Laight
2018-07-03 10:06     ` Jan Beulich
2018-07-03 10:29       ` David Laight
2018-07-03 11:59     ` Denys Vlasenko
2018-07-03 12:25       ` David Laight [this message]

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=4420eda360c240488f7ce38fd8baa778@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.