nasm-devel — NASM development work

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

We only require that there is a supported 64-bit integer type.

Cyrill Gorcunov <gor...@gm...> wrote:
>On Mon, Dec 09, 2013 at 09:55:10PM -0800, H. Peter Anvin wrote:
>> On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote:
>> > Commit-ID:  71f71c0dbe204d8d6a58e695c038bf0508d3b406
>> > Gitweb:    
>http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406
>> > Author:     Cyrill Gorcunov <gor...@gm...>
>> > AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400
>> > Committer:  Cyrill Gorcunov <gor...@gm...>
>> > CommitDate: Sat, 7 Dec 2013 16:12:07 +0400
>> > 
>> > iflag: Introduce IFLAG_INIT helper
>> > 
>> 
>> No, this once again introduces an unnecessary C99ism, which we really
>> are trying to avoid.
>
>Wait, Peter, don't we require the compiler to support C99?

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

On Mon, Dec 09, 2013 at 09:55:10PM -0800, H. Peter Anvin wrote:
> On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote:
> > Commit-ID:  71f71c0dbe204d8d6a58e695c038bf0508d3b406
> > Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406
> > Author:     Cyrill Gorcunov <gor...@gm...>
> > AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400
> > Committer:  Cyrill Gorcunov <gor...@gm...>
> > CommitDate: Sat, 7 Dec 2013 16:12:07 +0400
> > 
> > iflag: Introduce IFLAG_INIT helper
> > 
> 
> No, this once again introduces an unnecessary C99ism, which we really
> are trying to avoid.

Wait, Peter, don't we require the compiler to support C99?

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote:
> Commit-ID:  71f71c0dbe204d8d6a58e695c038bf0508d3b406
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406
> Author:     Cyrill Gorcunov <gor...@gm...>
> AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400
> Committer:  Cyrill Gorcunov <gor...@gm...>
> CommitDate: Sat, 7 Dec 2013 16:12:07 +0400
> 
> iflag: Introduce IFLAG_INIT helper
> 

No, this once again introduces an unnecessary C99ism, which we really
are trying to avoid.

	-hpa

Re: [Nasm-devel] NASM 2.11rc2

[anonymous c. <nas...@us...>]

>>>> The newly added "[foo,bar]" syntax seems to be giving
>>>> me trouble with some existing source code. I stand by
>>>> what I said before -- I would like to see it gone, in favor
>>>> of just the traditional comma-less "[foo+bar]" syntax.
>>>
>>> Could you give an example, perhaps?
>>
>> I haven't had a chance yet to track it down -- all I know
>> for now is that something fails as soon as that change
>> is in the tree.
>
> We'd really like something concrete here... it is almost impossible to
> judge the importance of this without seeing something.

After a lot of digging, I narrowed down the first problem.

Here is an abstract example:

| 1                                  bits 32
| 2
| 3                                  %define smac2(x,y)   x,y
| 4                                  %define smac3(x,y,z) x,y,z
| 5
| 6 00000000 0F1A043E                bndldx smac2(bnd0,[esi+edi])
| 7 00000004 0F1A043E                bndldx smac3(bnd0,[esi,edi])	;
requires 3-arg smac
| 8 00000008 0F1A043E                bndldx smac2(bnd0,{[esi,edi]})	;
 or explicit {...}

Note that I said "first problem"... because even with that
one "addressed" I am still seeing some other problem. I
do not yet know what is causing that one though -- more
work will be required.

I really see no good reason at all for the comma syntax.

Oh, and while we are at the topic of how painful MPX is,
you need to preclude rIP-relative addressing for BNDMK,
as well as BNDLDX and BNDSTX -- the spec says #UD.

Which really ruins the whole prior NOP behavior too.  :-(

Re: [Nasm-devel] NASM 2.11rc2

[H. P. A. <hp...@zy...>]

On 12/04/2013 08:33 PM, anonymous coward wrote:
>>> The newly added "[foo,bar]" syntax seems to be giving
>>> me trouble with some existing source code. I stand by
>>> what I said before -- I would like to see it gone, in favor
>>> of just the traditional comma-less "[foo+bar]" syntax.
>>
>> Could you give an example, perhaps?
> 
> I haven't had a chance yet to track it down -- all I know
> for now is that something fails as soon as that change
> is in the tree.

We'd really like something concrete here... it is almost impossible to
judge the importance of this without seeing something.

	-hpa

Re: [Nasm-devel] NASM 2.11rc2

[anonymous c. <nas...@us...>]

>> The newly added "[foo,bar]" syntax seems to be giving
>> me trouble with some existing source code. I stand by
>> what I said before -- I would like to see it gone, in favor
>> of just the traditional comma-less "[foo+bar]" syntax.
>
> Could you give an example, perhaps?

I haven't had a chance yet to track it down -- all I know
for now is that something fails as soon as that change
is in the tree.

Re: [Nasm-devel] HINT_NOP17

[H. P. A. <hp...@zy...>]

On 11/30/2013 05:02 PM, Song, Jin Kyu wrote:
> Hello,
> 
> I found bndldx and hint_nop17 sharing the same opcode (OF 1A). And, of course, ndisasm picks either one depending on the iflags now.
> 
> BNDLDX      bndreg,mem128  [rm:    0f 1a /r] MPX,MIB,FUTURE
> HINT_NOP17	rm32           [m: o32 0f 1a /1] P6,UNDOC
> 
> So is '[OF 1A /1] with a rm operand' still a nop? Shall I remove this NOP instruction or raise the priority of UNDOC iflag to let ndisasm know this is not preferred?
> 

Oh, right.  We really need to mask off the irrelevant flags (anything
but the vendor), otherwise the disassembler will do the wrong thing.

The HINT_NOPs really should be last priority, which is why they are at
the end of the file.

	-hpa

[Nasm-devel] HINT_NOP17

[Song, J. K. <jin...@in...>]

Hello,

I found bndldx and hint_nop17 sharing the same opcode (OF 1A). And, of course, ndisasm picks either one depending on the iflags now.

BNDLDX      bndreg,mem128  [rm:    0f 1a /r] MPX,MIB,FUTURE
HINT_NOP17	rm32           [m: o32 0f 1a /1] P6,UNDOC

So is '[OF 1A /1] with a rm operand' still a nop? Shall I remove this NOP instruction or raise the priority of UNDOC iflag to let ndisasm know this is not preferred?

Thanks,
Jin

Re: [Nasm-devel] [nasm:master] bnd: Drop bnd prefix for relaxed short jmp instructions

[H. P. A. <hp...@zy...>]

On 11/28/2013 04:52 PM, anonymous coward wrote:
>> And when a relaxed jmp instruction becomes a short (Jb) form,
>> bnd prefix is not needed because it does not initialize bnd registers.
>> So in that case, bnd prefix is silently dropped.
> 
> The assembler shouldn't silently drop explicitly specified prefixes.
> 
> You want a suppressible warning instead.

Hmm.  This is messy, because when you are writing MPX code you want
*all* your jumps that need them to have the BND prefix, but you don't
want to have to muck with the issue of short ones not needing it.

Perhaps what we need is a bnd option to the "default" directive?

	-hpa

Re: [Nasm-devel] NASM 2.11rc2

[H. P. A. <hp...@zy...>]

On 11/28/2013 05:09 PM, anonymous coward wrote:
>> I would like to do a 2.11 final next week.
> 
> The newly added "[foo,bar]" syntax seems to be giving
> me trouble with some existing source code. I stand by
> what I said before -- I would like to see it gone, in favor
> of just the traditional comma-less "[foo+bar]" syntax.
> 

Could you give an example, perhaps?

	-hpa

Re: [Nasm-devel] [nasm:master] AVX-512: Add {evex} instruction prefix

[H. P. A. <hp...@zy...>]

On 11/28/2013 10:09 PM, Marat Dukhan wrote:
> Some time ago I asked about a mechanism for fine-grained selection of
> instruction forms, which is similar to what you do with {evex}, {vec2} and
> {vec3} keywords.
> Here are the details:
> 
> http://comments.gmane.org/gmane.comp.lang.nasm.devel/3347
> http://forum.nasm.us/index.php?topic=1517
> 
> 
> Maybe you could implement selection between other forms (e.g. REX vs
> no-REX) as a part of your new selection mechanism?

A lot of it probably comes down to someone willing to do the work.  The
selection mechanism itself isn't the hard part, but making sure it
doesn't break anything is a big deal.

	-hpa

Re: [Nasm-devel] [nasm:master] AVX-512: Add {evex} instruction prefix

[Marat D. <ma...@gm...>]

Some time ago I asked about a mechanism for fine-grained selection of
instruction forms, which is similar to what you do with {evex}, {vec2} and
{vec3} keywords.
Here are the details:

http://comments.gmane.org/gmane.comp.lang.nasm.devel/3347
http://forum.nasm.us/index.php?topic=1517


Maybe you could implement selection between other forms (e.g. REX vs
no-REX) as a part of your new selection mechanism?

Regards,
Marat

On Thu, Nov 28, 2013 at 7:54 PM, Song, Jin Kyu <jin...@in...>wrote:

> > > For instructions that can be encoded either in VEX or EVEX,
> > > {evex} forces nasm to encode in EVEX.
> >
> > In addition to a per-instruction selection mechanism
> > you also want a global selection mechanism, i.e. an
> > assembler directive and a command line option. And
> > as a result of that, you then want {vex} as well.
>
> Yes, adding {vex} - actually {vex2} and {vex3} - is on my to-do list. I
> will implement that as soon as possible. A global selection mechanism is
> now added to my to-do list.
>
> Thanks,
> Jin
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-devel
>

Re: [Nasm-devel] [nasm:master] match: Improve broadcast opsize matching

[anonymous c. <nas...@us...>]

> Broadcasting operand size is different from the original
> operand size because 32b or 64b element is repeated to form a vector.
> So when matching a broadcasting operand, opsize should be treated differently.
> The broadcasting element size is specified in the decorator information.

Yes, a dword or qword is being broadcast... but what
size is used for the segmentation and paging check?
Is it just dword or qword, or the full zword? (That's the
size which NASM needs to follow.)

The AVX512F spec fails to document this aspect.  :-(

Re: [Nasm-devel] [nasm:master] bnd: Drop bnd prefix for relaxed short jmp instructions

[anonymous c. <nas...@us...>]

>> > And when a relaxed jmp instruction becomes a short (Jb) form,
>> > bnd prefix is not needed because it does not initialize bnd registers.
>> > So in that case, bnd prefix is silently dropped.
>>
>> The assembler shouldn't silently drop explicitly specified prefixes.
>>
>> You want a suppressible warning instead.
>
> I can do that right away. Do you think adding a new warning class for it
> will be a way to go? Or do you have any suggestion on implementing it?

How about

  #define ERR_WARN_BND WARN(14)

in nasmlib.h?

Re: [Nasm-devel] [nasm:master] AVX-512: Add {evex} instruction prefix

[anonymous c. <nas...@us...>]

>> > For instructions that can be encoded either in VEX or EVEX,
>> > {evex} forces nasm to encode in EVEX.
>>
>> In addition to a per-instruction selection mechanism
>> you also want a global selection mechanism, i.e. an
>> assembler directive and a command line option. And
>> as a result of that, you then want {vex} as well.
>
> Yes, adding {vex} - actually {vex2} and {vex3} - is on my to-do list. I will
> implement that as soon as possible. A global selection mechanism is now
> added to my to-do list.

I just spotted the change for {vex2} and {vex3}.

(I'm going through mail in chronological order.)

But yeah, having both, an assembler directive
and a command line option would be useful to
cope with large chunks of code.  :)

Re: [Nasm-devel] NASM 2.11rc2

[anonymous c. <nas...@us...>]

> I would like to do a 2.11 final next week.

The newly added "[foo,bar]" syntax seems to be giving
me trouble with some existing source code. I stand by
what I said before -- I would like to see it gone, in favor
of just the traditional comma-less "[foo+bar]" syntax.

Re: [Nasm-devel] [nasm:master] bnd: Drop bnd prefix for relaxed short jmp instructions

[Song, J. K. <jin...@in...>]

> > And when a relaxed jmp instruction becomes a short (Jb) form,
> > bnd prefix is not needed because it does not initialize bnd registers.
> > So in that case, bnd prefix is silently dropped.
> 
> The assembler shouldn't silently drop explicitly specified prefixes.
> 
> You want a suppressible warning instead.

I can do that right away. Do you think adding a new warning class for it will be a way to go? Or do you have any suggestion on implementing it?

- Jin

Re: [Nasm-devel] [nasm:master] AVX-512: Add {evex} instruction prefix

[Song, J. K. <jin...@in...>]

> > For instructions that can be encoded either in VEX or EVEX,
> > {evex} forces nasm to encode in EVEX.
> 
> In addition to a per-instruction selection mechanism
> you also want a global selection mechanism, i.e. an
> assembler directive and a command line option. And
> as a result of that, you then want {vex} as well.

Yes, adding {vex} - actually {vex2} and {vex3} - is on my to-do list. I will implement that as soon as possible. A global selection mechanism is now added to my to-do list.

Thanks,
Jin

Re: [Nasm-devel] [nasm:master] bnd: Drop bnd prefix for relaxed short jmp instructions

[anonymous c. <nas...@us...>]

> And when a relaxed jmp instruction becomes a short (Jb) form,
> bnd prefix is not needed because it does not initialize bnd registers.
> So in that case, bnd prefix is silently dropped.

The assembler shouldn't silently drop explicitly specified prefixes.

You want a suppressible warning instead.

Re: [Nasm-devel] [nasm:master] AVX-512: Add {evex} instruction prefix

[anonymous c. <nas...@us...>]

> For instructions that can be encoded either in VEX or EVEX,
> {evex} forces nasm to encode in EVEX.

In addition to a per-instruction selection mechanism
you also want a global selection mechanism, i.e. an
assembler directive and a command line option. And
as a result of that, you then want {vex} as well.

Re: [Nasm-devel] NASM 2.11rc2

[Cyrill G. <gor...@gm...>]

On Thu, Nov 28, 2013 at 11:37:46AM -0800, H. Peter Anvin wrote:
> With Jin's latest AVX512 changes, I have tagged NASM 2.11rc2 and pushed
> it out.
> 
> I would like to do a 2.11 final next week.

Sounds great to me, thanks!

[Nasm-devel] NASM 2.11rc2

[H. P. A. <hp...@zy...>]

With Jin's latest AVX512 changes, I have tagged NASM 2.11rc2 and pushed
it out.

I would like to do a 2.11 final next week.

	-hpa

Re: [Nasm-devel] Instruction flags engine is merged upstream

[H. P. A. <hp...@zy...>]

Awesome, thanks!

"Song, Jin Kyu" <jin...@in...> wrote:
>I verified again Cyrill's new iflags engine works very well with all
>the AVX512 functionalities - including ndisasm. 
>
>Thanks,
>Jin
>
>> -----Original Message-----
>> From: Cyrill Gorcunov [mailto:gor...@gm...]
>> Sent: Sunday, November 24, 2013 1:10 PM
>> To: H. Peter Anvin
>> Cc: nas...@li...; Song, Jin Kyu
>> Subject: Re: [Nasm-devel] Instruction flags engine is merged upstream
>> 
>> On Sun, Nov 24, 2013 at 01:05:46PM -0800, H. Peter Anvin wrote:
>> > On 11/24/2013 11:31 AM, Cyrill Gorcunov wrote:
>> > >
>> > > Hi Peter, sorry for delay, was out. Look, I can rollback my
>commits
>> > > restoring former master and move flags patches out of mainline to
>> > > a separate tree (just one revert for all commits, it'll be easy).
>> > > The reason I merged it into master was that -- without rebase
>I've
>> > > got a number of merge problems because of new IF_ flags
>introduced
>> > > into master, so the longer I stay out of mainline the harder it
>will
>> > > be to port back. But again, Peter, it's not a problem to revert,
>just
>> > > say a word ;)
>> >
>> > There is no reason to revert.  If it turns out to be a problem we
>can
>> > just fork a new branch off 305f3cee04d1adf3f4e335c5645814f2b67e8a69
>and
>> > then re-merge later.
>> 
>> OK, great. As far as I remember, Jin said the new engine is pretty
>fine
>> for him, still better to double check this moment.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [Nasm-devel] Instruction flags engine is merged upstream

[Cyrill G. <gor...@gm...>]

On Mon, Nov 25, 2013 at 05:38:34PM +0000, Song, Jin Kyu wrote:
> I verified again Cyrill's new iflags engine works very well with all the AVX512 functionalities - including ndisasm. 
> 

Thanks a lot, Jin!

Re: [Nasm-devel] Instruction flags engine is merged upstream

[Song, J. K. <jin...@in...>]

I verified again Cyrill's new iflags engine works very well with all the AVX512 functionalities - including ndisasm. 

Thanks,
Jin

> -----Original Message-----
> From: Cyrill Gorcunov [mailto:gor...@gm...]
> Sent: Sunday, November 24, 2013 1:10 PM
> To: H. Peter Anvin
> Cc: nas...@li...; Song, Jin Kyu
> Subject: Re: [Nasm-devel] Instruction flags engine is merged upstream
> 
> On Sun, Nov 24, 2013 at 01:05:46PM -0800, H. Peter Anvin wrote:
> > On 11/24/2013 11:31 AM, Cyrill Gorcunov wrote:
> > >
> > > Hi Peter, sorry for delay, was out. Look, I can rollback my commits
> > > restoring former master and move flags patches out of mainline to
> > > a separate tree (just one revert for all commits, it'll be easy).
> > > The reason I merged it into master was that -- without rebase I've
> > > got a number of merge problems because of new IF_ flags introduced
> > > into master, so the longer I stay out of mainline the harder it will
> > > be to port back. But again, Peter, it's not a problem to revert, just
> > > say a word ;)
> >
> > There is no reason to revert.  If it turns out to be a problem we can
> > just fork a new branch off 305f3cee04d1adf3f4e335c5645814f2b67e8a69 and
> > then re-merge later.
> 
> OK, great. As far as I remember, Jin said the new engine is pretty fine
> for him, still better to double check this moment.