Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Marc Espie]

H.J.Lu wrote:
> have the same concern as Alan. Unless ALL x86 assembly codes, open
> source or otherwise, not just those on OpenBSD, have been assembled
> correctly with the modified assembler, I don't think it should go into
> the FSF assembler.

We have something like >4G of source code between source, X, and ports
in OpenBSD. If that's not sufficient coverage, then I don't know what is.

Guys, OpenBSD is not a niche OS.  We compile a heck of a lot of stuff.

H.J., I also have a problem taking your statement seriously, considering
how often your patches break stuff that is not linux. Should we demand
that you test your patches on ALL OSes that use i386 before committing
a 386 change ?

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

   Date: Mon, 18 Apr 2005 14:14:20 +0930
   From: Alan Modra <amodra@bigpond.net.au>

   On Sat, Apr 16, 2005 at 01:40:00PM +0200, Mark Kettenis wrote:
   > Does this give enough confidence?

   Yes.  I'll OK the patch.

Thanks, it's in now.

Mark

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Alan Modra]

On Sat, Apr 16, 2005 at 01:40:00PM +0200, Mark Kettenis wrote:
> Does this give enough confidence?

Yes.  I'll OK the patch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

   Date: Thu, 14 Apr 2005 10:55:55 +0930
   From: Alan Modra <amodra@bigpond.net.au>

   On Wed, Apr 13, 2005 at 03:20:25PM +0000, Thorsten Glaser wrote:
   > DOES it fail then?

   :)  Note that I carefully said "Something like" the example I posted.

   I know that we had trouble in the past with the assembler pre-processor
   stripping whitespace completely (see tc_symbol_chars), but it may be
   that this can't happen now for the mnemonic part of an assembly line.

All tc_symbol_chars does is add a few more characters, including '-'
to the LEX_IS_SYMBOL_COMPONENT "class".  Since the alphanumeric
characters are already marked as LEX_IS_SYMBOL_COMPONENT, is exactly
the reason why the whitespace isn't stripped.  It makes us go from
state 3 to state 9 to state 10, which outputs a space, so whitespace
around the mnemonic (which is considered to be the first operand in
presence of a prefix) is conserved (even if '-' is the first or last
character of the operand.

   If one of the proponents of this patch analyse app.c behaviour enough to
   give a reasonable level of confidence, I'll accept the patch.

Does this give enough confidence?

Mark

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Alan Modra]

On Wed, Apr 13, 2005 at 03:20:25PM +0000, Thorsten Glaser wrote:
> DOES it fail then?

:)  Note that I carefully said "Something like" the example I posted.

I know that we had trouble in the past with the assembler pre-processor
stripping whitespace completely (see tc_symbol_chars), but it may be
that this can't happen now for the mnemonic part of an assembly line.

If one of the proponents of this patch analyse app.c behaviour enough to
give a reasonable level of confidence, I'll accept the patch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

   Date: Wed, 13 Apr 2005 12:29:52 -0700
   From: "H. J. Lu" <hjl@lucon.org>

   I have the same concern as Alan. Unless ALL x86 assembly codes, open
   source or otherwise, not just those on OpenBSD, have been assembled
   correctly with the modified assembler, I don't think it should go into
   the FSF assembler.

This is a ridiculous statement.

Mark

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[H. J. Lu]

On Wed, Apr 13, 2005 at 08:55:09PM +0200, Mark Kettenis wrote:
>    Date: Wed, 13 Apr 2005 10:07:55 +0930
>    From: Alan Modra <amodra@bigpond.net.au>
> 
>    On Tue, Apr 12, 2005 at 10:43:10PM +0200, Mark Kettenis wrote:
>    > Because there is already code out there that uses the hyphen.  The
>    > reason for preferring the hyphenated names over the unhyphenated names
>    > is that the former are used by the VIA documentation.
> 
>    I don't like the idea of putting '-' in mnemonic_chars.  I think it has
>    a high likelihood of breaking other valid assembly.  The gas app.c code
>    has a nasty habit of completely removing whitespace once past the
>    mnemonic of an instruction, and it can get confused.  Something like
> 
>     addr16 mov -2,%eax
> 
>    might fail if '-' is a valid mnemonic char.
> 
> Well, it doesn't fail.  The patch to tc-i386.c to allow '-' as a
> mnemonic char has been in the OpenBSD tree for more than a year now.
> That means all major Open Source software has been compiled with it.
> So I'd expect any problems with it would have surfaced by now.
> 

I have the same concern as Alan. Unless ALL x86 assembly codes, open
source or otherwise, not just those on OpenBSD, have been assembled
correctly with the modified assembler, I don't think it should go into
the FSF assembler.


H.J.

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

   Date: Wed, 13 Apr 2005 10:07:55 +0930
   From: Alan Modra <amodra@bigpond.net.au>

   On Tue, Apr 12, 2005 at 10:43:10PM +0200, Mark Kettenis wrote:
   > Because there is already code out there that uses the hyphen.  The
   > reason for preferring the hyphenated names over the unhyphenated names
   > is that the former are used by the VIA documentation.

   I don't like the idea of putting '-' in mnemonic_chars.  I think it has
   a high likelihood of breaking other valid assembly.  The gas app.c code
   has a nasty habit of completely removing whitespace once past the
   mnemonic of an instruction, and it can get confused.  Something like

    addr16 mov -2,%eax

   might fail if '-' is a valid mnemonic char.

Well, it doesn't fail.  The patch to tc-i386.c to allow '-' as a
mnemonic char has been in the OpenBSD tree for more than a year now.
That means all major Open Source software has been compiled with it.
So I'd expect any problems with it would have surfaced by now.

Mark

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Thorsten Glaser]

Jan Beulich dixit:

>>Alternatively, we'd need to make a way for a dash to be only
>>recognised as part of a mnemonic if followed by a letter.
>
>That wouldn't help either:
>
>	.equiv two, 2
>	movl -two(%ebx), %eax
>
>would still fail.

.oO(noone sane uses AT&T syntax anyway)

Well, then one has to fix gas, I assume.

DOES it fail then?

tg@herc:/home/tg $ objdump -d a.out

a.out:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   8b 43 fe                mov    0xfffffffe(%ebx),%eax
tg@herc:/home/tg $ cat x.s
        .text
        .equiv two, 2
        movl -two(%ebx), %eax


Doesn't look like it (and yes, I have Marks patches
applied, since MirOS is an OpenBSD derivate, I need
it for the VIA code in the kernel).

bye,
//mirabile

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Jan Beulich]

>>> Thorsten Glaser <tg@66h.42h.de> 13.04.05 12:42:35 >>>
>Alan Modra dixit:
>
>>a high likelihood of breaking other valid assembly.  The gas app.c code
>>has a nasty habit of completely removing whitespace once past the
>>mnemonic of an instruction, and it can get confused.  Something like
>>
>> addr16 mov -2,%eax
>>
>>might fail if '-' is a valid mnemonic char.
>
>Can't gas be fixed, then? Sounds like the "obvious" thing to do to me.
>
>Alternatively, we'd need to make a way for a dash to be only
>recognised as part of a mnemonic if followed by a letter.

That wouldn't help either:

	.equiv two, 2
	movl -two(%ebx), %eax

would still fail.

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Thorsten Glaser]

Alan Modra dixit:

>a high likelihood of breaking other valid assembly.  The gas app.c code
>has a nasty habit of completely removing whitespace once past the
>mnemonic of an instruction, and it can get confused.  Something like
>
> addr16 mov -2,%eax
>
>might fail if '-' is a valid mnemonic char.

Can't gas be fixed, then? Sounds like the "obvious" thing to do to me.

Alternatively, we'd need to make a way for a dash to be only
recognised as part of a mnemonic if followed by a letter.

//mirabile

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Alan Modra]

On Tue, Apr 12, 2005 at 10:43:10PM +0200, Mark Kettenis wrote:
> Because there is already code out there that uses the hyphen.  The
> reason for preferring the hyphenated names over the unhyphenated names
> is that the former are used by the VIA documentation.

I don't like the idea of putting '-' in mnemonic_chars.  I think it has
a high likelihood of breaking other valid assembly.  The gas app.c code
has a nasty habit of completely removing whitespace once past the
mnemonic of an instruction, and it can get confused.  Something like

 addr16 mov -2,%eax

might fail if '-' is a valid mnemonic char.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

   Date: Wed, 13 Apr 2005 08:32:26 +1200
   From: Michal Ludvig <michal@logix.cz>

   Mark Kettenis wrote:
   > This one is a bit nasty.  The OpenBSD in-tree gas has had support for
   > the VIA PadLock instructions for a while.  Unfortunately that support
   > was never submitted for inclusion into the FSF tree.  A little over a
   > year ago Michal Ludvig committed support for these instructions.
   > Unfortunately he used mnemonics that differ from the instruction names
   > as used in the VIA documentation; the VIA names include a hyphen that
   > Michal left out.  I presume Michal did this because gas doesn't accept
   > hyphens in mnemonics.  That can be fixed though.  This patch does
   > that, and adds back the missing hyphen.  It also adds a missing
   > instruction that's going to be in the VIA cpu.
   > 
   > This patch keeps hyphen-less aliases for the instructions.  The gas
   > testsuite still passes with this patch applied.

   As long as the names without hyphen still exist I don't object.
   Coincidently in Linux Journal of May 05 there is an article about VIA
   PadLock that uses the current short names (obviously).

Code using the names without the hyphen will still assemble fine.

   However, what is the point of having two names for one instruction? Why
   not to support only the one without hyphen?

Because there is already code out there that uses the hyphen.  The
reason for preferring the hyphenated names over the unhyphenated names
is that the former are used by the VIA documentation.

Cheers,

Mark

Re: [RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Michal Ludvig]

Mark Kettenis wrote:
> This one is a bit nasty.  The OpenBSD in-tree gas has had support for
> the VIA PadLock instructions for a while.  Unfortunately that support
> was never submitted for inclusion into the FSF tree.  A little over a
> year ago Michal Ludvig committed support for these instructions.
> Unfortunately he used mnemonics that differ from the instruction names
> as used in the VIA documentation; the VIA names include a hyphen that
> Michal left out.  I presume Michal did this because gas doesn't accept
> hyphens in mnemonics.  That can be fixed though.  This patch does
> that, and adds back the missing hyphen.  It also adds a missing
> instruction that's going to be in the VIA cpu.
> 
> This patch keeps hyphen-less aliases for the instructions.  The gas
> testsuite still passes with this patch applied.

As long as the names without hyphen still exist I don't object.
Coincidently in Linux Journal of May 05 there is an article about VIA
PadLock that uses the current short names (obviously).

However, what is the point of having two names for one instruction? Why
not to support only the one without hyphen?

Michal Ludvig
-- 
* Personal homepage: http://www.logix.cz/michal

[RFC/RFA] Proper mnemonics for VIA PadLock (i386) instructions

[Mark Kettenis]

This one is a bit nasty.  The OpenBSD in-tree gas has had support for
the VIA PadLock instructions for a while.  Unfortunately that support
was never submitted for inclusion into the FSF tree.  A little over a
year ago Michal Ludvig committed support for these instructions.
Unfortunately he used mnemonics that differ from the instruction names
as used in the VIA documentation; the VIA names include a hyphen that
Michal left out.  I presume Michal did this because gas doesn't accept
hyphens in mnemonics.  That can be fixed though.  This patch does
that, and adds back the missing hyphen.  It also adds a missing
instruction that's going to be in the VIA cpu.

This patch keeps hyphen-less aliases for the instructions.  The gas
testsuite still passes with this patch applied.

OK?

Mark


Index: gas/ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* config/tc-i386.c (md_begin): Allow hyphens in mnemonics.

Index: include/opcode/ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* i386.h: Insert hyphens into selected VIA PadLock extensions.
	Add xcrypt-ctr.  Provide aliases without hyphens.

Index: opcodes/ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* i386-dis.c: Insert hyphens into selected VIA PadLock extensions.
	Add xcrypt-ctr.

Index: gas/config/tc-i386.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-i386.c,v
retrieving revision 1.173
diff -u -p -r1.173 tc-i386.c
--- gas/config/tc-i386.c 12 Apr 2005 17:12:33 -0000 1.173
+++ gas/config/tc-i386.c 12 Apr 2005 19:01:12 -0000
@@ -1008,6 +1008,7 @@ md_begin ()
     operand_chars['?'] = '?';
 #endif
     digit_chars['-'] = '-';
+    mnemonic_chars['-'] = '-';
     identifier_chars['_'] = '_';
     identifier_chars['.'] = '.';
Index: include/opcode/i386.h
===================================================================
RCS file: /cvs/src/src/include/opcode/i386.h,v
retrieving revision 1.56
diff -u -p -r1.56 i386.h
--- include/opcode/i386.h 12 Apr 2005 17:12:30 -0000 1.56
+++ include/opcode/i386.h 12 Apr 2005 19:01:16 -0000
@@ -1378,15 +1378,23 @@ static const template i386_optab[] =
 {"rdtscp",   0, 0x0f01, 0xf9, CpuSledgehammer,NoSuf|ImmExt,	{ 0, 0, 0} },
 
 /* VIA PadLock extensions.  */
+{"xstore-rng",0, 0x000fa7, 0xc0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcrypt-ecb",0, 0xf30fa7, 0xc8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcrypt-cbc",0, 0xf30fa7, 0xd0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcrypt-ctr",0, 0xf30fa7, 0xd8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcrypt-cfb",0, 0xf30fa7, 0xe0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcrypt-ofb",0, 0xf30fa7, 0xe8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"montmul",   0, 0xf30fa6, 0xc0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xsha1",     0, 0xf30fa6, 0xc8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xsha256",   0, 0xf30fa6, 0xd0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+/* Aliases without hyphens.  */
 {"xstorerng", 0, 0x000fa7, 0xc0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
 {"xcryptecb", 0, 0xf30fa7, 0xc8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
 {"xcryptcbc", 0, 0xf30fa7, 0xd0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
+{"xcryptctr", 0, 0xf30fa7, 0xd8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
 {"xcryptcfb", 0, 0xf30fa7, 0xe0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
 {"xcryptofb", 0, 0xf30fa7, 0xe8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
-{"montmul",   0, 0xf30fa6, 0xc0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
-{"xsha1",     0, 0xf30fa6, 0xc8, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
-{"xsha256",   0, 0xf30fa6, 0xd0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
-/* Alias for xstorerng.  */
+/* Alias for xstore-rng.  */
 {"xstore",    0, 0x000fa7, 0xc0, Cpu686|CpuPadLock, NoSuf|IsString|ImmExt, { 0, 0, 0} },
 
 /* sentinel */
Index: opcodes/i386-dis.c
===================================================================
RCS file: /cvs/src/src/opcodes/i386-dis.c,v
retrieving revision 1.58
diff -u -p -r1.58 i386-dis.c
--- opcodes/i386-dis.c 1 Apr 2005 16:06:40 -0000 1.58
+++ opcodes/i386-dis.c 12 Apr 2005 19:01:19 -0000
@@ -1469,14 +1469,14 @@ static const struct dis386 grps[][8] = {
   },
   /* GRPPADLCK1 */
   {
-    { "xstorerng", OP_0f07, 0, XX, XX },
-    { "xcryptecb", OP_0f07, 0, XX, XX },
-    { "xcryptcbc", OP_0f07, 0, XX, XX },
-    { "(bad)",	   OP_0f07, 0, XX, XX },
-    { "xcryptcfb", OP_0f07, 0, XX, XX },
-    { "xcryptofb", OP_0f07, 0, XX, XX },
-    { "(bad)",	   OP_0f07, 0, XX, XX },
-    { "(bad)",	   OP_0f07, 0, XX, XX },
+    { "xstore-rng", OP_0f07, 0, XX, XX },
+    { "xcrypt-ecb", OP_0f07, 0, XX, XX },
+    { "xcrypt-cbc", OP_0f07, 0, XX, XX },
+    { "xcrypt-ctr", OP_0f07, 0, XX, XX },
+    { "xcrypt-cfb", OP_0f07, 0, XX, XX },
+    { "xcrypt-ofb", OP_0f07, 0, XX, XX },
+    { "(bad)",	OP_0f07, 0, XX, XX },
+    { "(bad)",	OP_0f07, 0, XX, XX },
   },
   /* GRPPADLCK2 */
   {