nasm-devel — NASM development work

Re: [Nasm-devel] [PATCH] Allow --v for version

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

On Wed, Jan 08, 2014 at 09:50:55AM -0800, H. Peter Anvin wrote:
> > 
> > Good point! I'll take a look once time permit. (Or if someone beat me
> > on this I won't mind ;)
> > 
> 
> So yes... I do have a copy of getopt_long() in klibc, which is
> MIT-licensed (equivalent to 2-BSD) and thus we can just use it.  I'm the
> copyright holder anyway, so if I say we can use it we can.

Cool! This simplifies all the things. Once I finish conversion I'll poke.

Re: [Nasm-devel] [PATCH] Allow --v for version

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

On 01/08/2014 09:43 AM, Cyrill Gorcunov wrote:
> On Wed, Jan 08, 2014 at 09:40:19AM -0800, H. Peter Anvin wrote:
>>>
>>> I don't see a reason why can't we. I've udated patch a bit though. Peter?
>>
>> Presumably we should handle both --v and --version, but I'd prefer if we
>> actually implemented the second '-' as a separate case clause and did
>> whole string comparisons, for future use.
>>
>> Even better might be to adopt getopt_long(), I think I have a
>> BSD-licensed implementation of getopt_long() sitting around somewhere...
> 
> Good point! I'll take a look once time permit. (Or if someone beat me
> on this I won't mind ;)
> 

So yes... I do have a copy of getopt_long() in klibc, which is
MIT-licensed (equivalent to 2-BSD) and thus we can just use it.  I'm the
copyright holder anyway, so if I say we can use it we can.

	-hpa

Re: [Nasm-devel] [PATCH] Allow --v for version

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

On Wed, Jan 08, 2014 at 09:40:19AM -0800, H. Peter Anvin wrote:
> > 
> > I don't see a reason why can't we. I've udated patch a bit though. Peter?
> 
> Presumably we should handle both --v and --version, but I'd prefer if we
> actually implemented the second '-' as a separate case clause and did
> whole string comparisons, for future use.
> 
> Even better might be to adopt getopt_long(), I think I have a
> BSD-licensed implementation of getopt_long() sitting around somewhere...

Good point! I'll take a look once time permit. (Or if someone beat me
on this I won't mind ;)

Re: [Nasm-devel] [PATCH] Allow --v for version

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

On 01/08/2014 07:17 AM, Cyrill Gorcunov wrote:
> On Mon, Jan 06, 2014 at 03:01:44PM -0700, Andy Willis wrote:
>> Long patch description:  NASM and yasm are in many respects compatible 
>> but yasm uses --v instead of -v for version.  As often --v is used for 
>> version I end up using --v initially in NASM.  This patch allows me to 
>> compile Mozilla apps which use yasm with NASM by merely renaming NASM to 
>> yasm so that the build environment does not have to be updated (Mozilla 
>> would not accept changes to allow use of NASM).  The patch is trivial 
>> and as such should not affect any other use case that I can see.
> ---
> 
> I don't see a reason why can't we. I've udated patch a bit though. Peter?

Presumably we should handle both --v and --version, but I'd prefer if we
actually implemented the second '-' as a separate case clause and did
whole string comparisons, for future use.

Even better might be to adopt getopt_long(), I think I have a
BSD-licensed implementation of getopt_long() sitting around somewhere...

	-hpa

Re: [Nasm-devel] [PATCH] Allow --v for version

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

On Mon, Jan 06, 2014 at 03:01:44PM -0700, Andy Willis wrote:
> Long patch description:  NASM and yasm are in many respects compatible 
> but yasm uses --v instead of -v for version.  As often --v is used for 
> version I end up using --v initially in NASM.  This patch allows me to 
> compile Mozilla apps which use yasm with NASM by merely renaming NASM to 
> yasm so that the build environment does not have to be updated (Mozilla 
> would not accept changes to allow use of NASM).  The patch is trivial 
> and as such should not affect any other use case that I can see.
---

I don't see a reason why can't we. I've udated patch a bit though. Peter?
---
From: Cyrill Gorcunov <gor...@gm...>
Date: Wed, 8 Jan 2014 19:14:52 +0400
Subject: [PATCH] nasm: Show version for --v option

This allows to compile Mozilla apps which use YASM with NASM
by merely renaming yasm to nasm, so that the build environment
does not have to be updated.

Based on patch from Andy Willis <abw...@gm...>

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 nasm.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/nasm.c b/nasm.c
index 2bb3029..5f63b27 100644
--- a/nasm.c
+++ b/nasm.c
@@ -635,6 +635,12 @@ struct textargs textopts[] = {
     {NULL, 0}
 };
 
+static void show_version(void)
+{
+    printf("NASM version %s compiled on %s%s\n",
+           nasm_version, nasm_date, nasm_compile_options);
+}
+
 static bool stopoptions = false;
 static bool process_arg(char *p, char *q)
 {
@@ -776,7 +782,7 @@ static bool process_arg(char *p, char *q)
                 ("usage: nasm [-@ response file] [-o outfile] [-f format] "
                  "[-l listfile]\n"
                  "            [options...] [--] filename\n"
-                 "    or nasm -v   for version info\n\n"
+                 "    or nasm (-v|--v) for version info\n\n"
                  "    -t          assemble in SciTech TASM compatible mode\n"
                  "    -g          generate debug information in selected format\n");
             printf
@@ -842,8 +848,7 @@ static bool process_arg(char *p, char *q)
             break;
 
         case 'v':
-            printf("NASM version %s compiled on %s%s\n",
-                   nasm_version, nasm_date, nasm_compile_options);
+            show_version();
             exit(0);    /* never need usage message here */
             break;
 
@@ -972,6 +977,10 @@ set_warning:
                     }
                 default:
                     {
+                        if (p[1] == '-' && p[2] == 'v') {
+                            show_version();
+                            exit(0);
+                        }
                         nasm_error(ERR_NONFATAL | ERR_NOFILE | ERR_USAGE,
                                      "unrecognised option `--%s'", p + 2);
                         break;
-- 
1.8.3.1

[Nasm-devel] [PATCH] Allow --v for version

[Andy W. <abw...@gm...>]

Long patch description:  NASM and yasm are in many respects compatible 
but yasm uses --v instead of -v for version.  As often --v is used for 
version I end up using --v initially in NASM.  This patch allows me to 
compile Mozilla apps which use yasm with NASM by merely renaming NASM to 
yasm so that the build environment does not have to be updated (Mozilla 
would not accept changes to allow use of NASM).  The patch is trivial 
and as such should not affect any other use case that I can see.

--- a/nasm.c
+++ b/nasm.c
@@ -653,6 +653,10 @@ static bool process_arg(char *p, char *q)
                  return advance;
          }

+    if (p[1] == '-' && p[2] == 'v') {
+        p[1] = 'v';
+        }
+
          switch (p[1]) {
          case 's':
              error_file = stdout;
@@ -777,6 +781,7 @@ static bool process_arg(char *p, char *q)
                   "[-l listfile]\n"
                   "            [options...] [--] filename\n"
                   "    or nasm -v   for version info\n\n"
+                 "    or nasm --v   for version info\n\n"
                   "    -t          assemble in SciTech TASM compatible 
mode\n"
                   "    -g          generate debug information in 
selected format\n");
              printf


Signed-off-by: Andy Willis <abw...@gm...>

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

>> what is the specific behavior you rely on,

This, as introduced in NASM 0.96.
> 8B044500000000          mov eax,[nosplit eax+eax]
> 8B044500000000          mov eax,[nosplit eax*2]

And this, as introduced in NASM 0.98.34.
> 8B040500000000          mov eax,[nosplit eax]
> 8B040500000000          mov eax,[nosplit eax*1]

Not this, as now changed in NASM 2.11.
> 8B0400                  mov eax,[nosplit eax+eax]

Nor this, as now changed in NASM 2.11.
> 8B00                    mov eax,[nosplit eax]

That is, explicit NOSPLIT shouldn't just be ignored for [reg] or [reg+reg].

>> what made you rely on that specific behavior,

Using explicit NOSPLIT gave the desired base-less SIB encoding.

>> and how would this naturally appear in programmers' code?

Whenever explicit NOSPLIT is used to get the base-less SIB encoding.

> All those are important.

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

On 01/01/2014 07:06 AM, anonymous coward wrote:
>> You are at not proving any rationale, which is where this discussion ends up going in circles...
> 
> What rationale are you looking for?
> 
> Why 0.96 honors NOSPLIT for both, [reg+reg] and [reg*2]?
> Ask Simon and Jules -- they introduced that behavior.

I strongly believe that was a historical accident of the implementation.

> Why 0.98.34 honors NOSPLIT for both, [reg] and [reg*1]?
> Because that way it matched the existing 2x behavior.

... thus acerbating the problem.

> Why 2.11 no longer honors NOSPLIT for [reg] or [reg+reg]?
> This breaks existing code. So I question its rationale.

You give no details about your code base despite repeated requests,
which makes it hard to use it to make design decisions.  As previously
stated:

> what is the specific behavior you rely on,
> what made you rely on that specific behavior, and how would this
> naturally appear in programmers' code? 

All those are important.

	-hpa

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

> You are at not proving any rationale, which is where this discussion ends up going in circles...

What rationale are you looking for?

Why 0.96 honors NOSPLIT for both, [reg+reg] and [reg*2]?
Ask Simon and Jules -- they introduced that behavior.

Why 0.98.34 honors NOSPLIT for both, [reg] and [reg*1]?
Because that way it matched the existing 2x behavior.

Why 2.11 no longer honors NOSPLIT for [reg] or [reg+reg]?
This breaks existing code. So I question its rationale.

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

You are at not proving any rationale, which is where this discussion ends up going in circles...

anonymous coward <nas...@us...> wrote:
>> To put things differently: what is the specific behavior you rely on,
>
>The code base I am faced with contains instances of both
>the "reg times 1" and "reg times 2" cases, each with both
>natural (e.g. [reg] or [reg+rex]) and explicit (e.g. [reg*1] or
>[reg*2]) uses. An explicit NOSPLIT qualifier is used when-
>ever a SIB encoding without a base register is desired.
>
>> what made you rely on that specific behavior,
>
>The "reg times 2" case worked since 0.96 (late 1997).
>
>The "reg times 1" case worked since 0.98.34 (mid 2002).
>
>> and how would this naturally appear in programmers' code?
>
>Via explicitly specified NOSPLIT qualifiers.
>
>>> [reg times 1]
>>
>> It has been undocumented all along, and looks nothing so much as an
>> unintentional consequence of Debbie, who implemented this, not
>wanting
>> to deal with distinguishing "reg*1" from "reg".  So when you say
>> "intentional/expected behavior" I would argue it is very questionable
>on
>> both fronts.
>
>The feature request asked for -- and got -- a rather specific
>behavior: permit NOSPLIT not just for the "reg times 2" but
>also for the "reg times 1" case.
>
>The blame for not getting this 0.98.34 change documented
>should fall on me -- I should have spotted the lack of a doc
>change in Debbie's commit... but failed to do so.

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

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

> To put things differently: what is the specific behavior you rely on,

The code base I am faced with contains instances of both
the "reg times 1" and "reg times 2" cases, each with both
natural (e.g. [reg] or [reg+rex]) and explicit (e.g. [reg*1] or
[reg*2]) uses. An explicit NOSPLIT qualifier is used when-
ever a SIB encoding without a base register is desired.

> what made you rely on that specific behavior,

The "reg times 2" case worked since 0.96 (late 1997).

The "reg times 1" case worked since 0.98.34 (mid 2002).

> and how would this naturally appear in programmers' code?

Via explicitly specified NOSPLIT qualifiers.

>> [reg times 1]
>
> It has been undocumented all along, and looks nothing so much as an
> unintentional consequence of Debbie, who implemented this, not wanting
> to deal with distinguishing "reg*1" from "reg".  So when you say
> "intentional/expected behavior" I would argue it is very questionable on
> both fronts.

The feature request asked for -- and got -- a rather specific
behavior: permit NOSPLIT not just for the "reg times 2" but
also for the "reg times 1" case.

The blame for not getting this 0.98.34 change documented
should fall on me -- I should have spotted the lack of a doc
change in Debbie's commit... but failed to do so.

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

On 12/31/2013 04:16 PM, H. Peter Anvin wrote:
>>
>> An explicit NOSPLIT isn't something that NASM
>> can just ignore.
> 
> [nosplit eax+eax] generating [nosplit eax*2] seems like nothing so much
> as a bug.  Seriously.  What on Earth would lead you to rely on such
> insane behavior?
> 

To put things differently: what is the specific behavior you rely on,
what made you rely on that specific behavior, and how would this
naturally appear in programmers' code?  Your previous communications on
this have been very hard to extract that kind of information from.

For example, you write:

>> [nosplit eax] has been encoded as [eax*1+0] since 0.98.34.
>> But this seems like unexpected behavior.
> 
> Actually, it is intentional/expected behavior.

It has been undocumented all along, and looks nothing so much as an
unintentional consequence of Debbie, who implemented this, not wanting
to deal with distinguishing "reg*1" from "reg".  So when you say
"intentional/expected behavior" I would argue it is very questionable on
both fronts.

	-hpa

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

On 12/31/2013 04:16 PM, H. Peter Anvin wrote:
> 
> [nosplit eax+eax] generating [nosplit eax*2] seems like nothing so much
> as a bug.  Seriously.  What on Earth would lead you to rely on such
> insane behavior?
> 

The intent here is that with NOSPLIT the EA should fit into the
[base+index*scale+disp] format -- this is straightforward,
self-consistent and should be backwards compatible.  This does change
the behavior of some previously ill-defined forms, which is unfortunate,
but given the lack of care that went into some periods of NASM
development I'm not sure it can be made consistent with that, at least
without some kind of quirks mechanism which I'm loathe to add, but will
if absolutely necessary.

	-hpa

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

On 12/31/2013 03:09 PM, anonymous coward wrote:
> On 12/19/13, anonymous coward <nas...@us...> wrote:
>>> [nosplit eax+eax] was encoded [eax*2] previously but
>>> this seems against the user's intention.
>>
>> Actually, it is intentional/expected behavior.
>>
>>> So in this case, nosplit is ignored now and [eax+eax] will be generated.
>>
>> See my other reply to Peter for more detail.
> 
> This change made it into 2.11, and as a result it
> is now breaking existing code for me. Please do
> back it out, or add an option to control this, with
> a default to the original behavior.
> 
> An explicit NOSPLIT isn't something that NASM
> can just ignore.
> 

[nosplit eax+eax] generating [nosplit eax*2] seems like nothing so much
as a bug.  Seriously.  What on Earth would lead you to rely on such
insane behavior?

	-hpa

Re: [Nasm-devel] [ANNOUNSE] nasm-2.11

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

> new major NASM 2.11 release

It broke the existing NOSPLIT behavior.  :-(

Re: [Nasm-devel] [nasm:master] nosplit: Generate index-only EA only when a multiplier is used.

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

On 12/19/13, anonymous coward <nas...@us...> wrote:
>> nosplit: Generate index-only EA only when a multiplier is used.
>>
>> [nosplit eax] has been encoded as [eax*1+0] since 0.98.34.
>> But this seems like unexpected behavior.
>
> Actually, it is intentional/expected behavior.
>
>> So only when a register is multiplied, that will be treated
>> as an index. ([nosplit eax*1] -> [eax*1+0])
>
> See my other reply to Peter for more detail.

This change made it into 2.11, and as a result it
is now breaking existing code for me. Please do
back it out, or add an option to control this, with
a default to the original behavior.

An explicit NOSPLIT isn't something that NASM
can just ignore.

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

On 12/19/13, anonymous coward <nas...@us...> wrote:
>> [nosplit eax+eax] was encoded [eax*2] previously but
>> this seems against the user's intention.
>
> Actually, it is intentional/expected behavior.
>
>> So in this case, nosplit is ignored now and [eax+eax] will be generated.
>
> See my other reply to Peter for more detail.

This change made it into 2.11, and as a result it
is now breaking existing code for me. Please do
back it out, or add an option to control this, with
a default to the original behavior.

An explicit NOSPLIT isn't something that NASM
can just ignore.

[Nasm-devel] [ANNOUNSE] nasm-2.11

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

Hi all! We're proud to announce new major NASM 2.11 release. It consist
of a few bugfixes and support for new AVX512 instructions set. In particular

 - support for long section names in COFF files

 - completely reworked internal engine to track instruction flags, at moment
   it works as before but open doors up for more precise filering of instructions
   bound to a particular cpu family

 - New AVX512/MPX/SHA instructions set support. This was the most hard part to
   implement and required significant efforts. Being completely new they required
   to extend syntax used to describe instructions.

See full list of changes at http://www.nasm.us/doc/nasmdocc.html

Happy New Year!

Re: [Nasm-devel] [nosplit eax]

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

On 12/19/13, H. Peter Anvin <hp...@zy...> wrote:
> On 12/19/2013 04:35 AM, anonymous coward wrote:
>>> Apparently [nosplit eax] is treated as if it was [nosplit eax*1], which
>>> was a deliberate patch introduced by Debbie in 0.98.34.  This is rather
>>> unexpected behavior, and I would really like to change it so that
>>> nosplit means "the term with the multiplication is the index".  This is
>>> a change, but does anyone anticipate a problem with doing this?
>>
>> tl;dr = keep NOSPLIT unchanged, but prevent *2 opt with MPX
>>
>> Historically NASM's goal has always been to emit the shortest
>> possible encoding. As a result, (nobase+)reg(*1) becomes just
>> reg (which does emit a sib-less encoding), and (nobase+)reg*2
>> becomes reg+reg*1 (which does emit a disp-less sib encoding
>> rather than a sib encoding with a signed dword disp). To give a
>> user the ability to emit the longer encodings when desired, the
>> NOSPLIT qualifier was added. Initially it only handled the case
>> of *2 (and that is documented) but eventually support for *1 got
>> added as well (but apparently not documented properly). Under
>>
>>   http://sourceforge.net/p/nasm/feature-requests/5/
>>
>> you can see the original feature request. From me, actually.  :)
>>
>> That said, NOSPLIT is working as intended (though the *1 case
>> ought to be documented). Please refrain from breaking it, since
>> that will break existing code. Likewise, please don't change the
>> existing reg*1 or reg*2 behavior, i.e. don't suddenly interpret an
>> explicit *1 or *2 as a request for a longer encoding -- since that
>> too will break existing code.
>>
>> In terms of BNDMK, BNDLDX, and BNDSTX, the [reg] case as
>> well as the [NOSPLIT reg] case are fine. The [NOSPLIT reg*2]
>> case is fine as well (though BNDLDX and BNDSTX now need a
>> warning for the resulting scale=2); however, the [reg*2] case is
>> of course problematic since NASM turns it into [reg+reg] which
>> has a base that the user did not specify. Since MPX is new, it
>> looks like disabling that case of *2 splitting is the right choice.
>
> I think this is horribly confusing.  It at least is consistent if you
> require a multiplier on the index operand.  What we *obviously* cannot
> break is [nosplit eax*1] ... that must work and produce a SIB.  The
> unadorned thing I fear is confusing as hell.

The default behavior of "give me the shortest encoding" is useful.

Having to add the explicit NOSPLIT qualifier when reg*1 or reg*2
is desired (i.e. a longer encoding) seems pretty reasonable too.

Speaking of NOSPLIT... there is another scenario for which one
needs an explicit qualifier: picking scale=1/2/4/8 for SIB that has
no index register. When that one came up back in 2004 I ended
up with SIB0/SIB1/SIB2/SIB3 qualifiers. The original SF request:

  http://sourceforge.net/p/nasm/feature-requests/6/

The rest is pretty straight forward as well -- handling *3/*5/*9, or
base/index swapping, or regs that can't be base... each of these
has to be applied, because the alternative would be to error out.

Last but not least, there is one more feature that is useful: being
able to get a suppressible warning for EAs that default to SS not
DS, i.e. when base=BP/EBP/RBP or base=ESP/RSP, and there
was no explicit DS: or SS: prefix. Handy for DS != SS scenarios.

> If we do the sane thing, we could perhaps also make split/nosplit
> permitted DEFAULT options.

The default would have to be the existing behavior, to ensure that
existing code doesn't break. Also, any explicit NOSPLIT (as well
as e.g. SIBn -- see above) would have to be honored. Which then
would leave the new option with two cases: "reg*1 -> reg" as well
as "reg*2 -> reg+reg", and the "mandatory" transformations (such
as *3/*5/*9, base<->index, base->index). Is it a worthwhile option?

In short, I find the existing behavior quite reasonable. Whether the
various EA transformations should -- when it comes to MPX -- be
applied (with warnings) or disabled (leading to errors) is a matter of
debate. I don't have a strong opinion on that one -- MPX is ugly no
matter what... not a clean and elegant x86 extension this one: not
enough bounds registers, awful EA abuse, claims of compatibility
with prior NOPs vs a new #UD on the rIP-relative encoding, default
to 32- vs 64-bit based on mode instead of address size, etc. etc.

Re: [Nasm-devel] [nosplit eax]

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

On 12/19/2013 04:35 AM, anonymous coward wrote:
>> Apparently [nosplit eax] is treated as if it was [nosplit eax*1], which
>> was a deliberate patch introduced by Debbie in 0.98.34.  This is rather
>> unexpected behavior, and I would really like to change it so that
>> nosplit means "the term with the multiplication is the index".  This is
>> a change, but does anyone anticipate a problem with doing this?
> 
> tl;dr = keep NOSPLIT unchanged, but prevent *2 opt with MPX
> 
> Historically NASM's goal has always been to emit the shortest
> possible encoding. As a result, (nobase+)reg(*1) becomes just
> reg (which does emit a sib-less encoding), and (nobase+)reg*2
> becomes reg+reg*1 (which does emit a disp-less sib encoding
> rather than a sib encoding with a signed dword disp). To give a
> user the ability to emit the longer encodings when desired, the
> NOSPLIT qualifier was added. Initially it only handled the case
> of *2 (and that is documented) but eventually support for *1 got
> added as well (but apparently not documented properly). Under
> 
>   http://sourceforge.net/p/nasm/feature-requests/5/
> 
> you can see the original feature request. From me, actually.  :)
> 
> That said, NOSPLIT is working as intended (though the *1 case
> ought to be documented). Please refrain from breaking it, since
> that will break existing code. Likewise, please don't change the
> existing reg*1 or reg*2 behavior, i.e. don't suddenly interpret an
> explicit *1 or *2 as a request for a longer encoding -- since that
> too will break existing code.
> 
> In terms of BNDMK, BNDLDX, and BNDSTX, the [reg] case as
> well as the [NOSPLIT reg] case are fine. The [NOSPLIT reg*2]
> case is fine as well (though BNDLDX and BNDSTX now need a
> warning for the resulting scale=2); however, the [reg*2] case is
> of course problematic since NASM turns it into [reg+reg] which
> has a base that the user did not specify. Since MPX is new, it
> looks like disabling that case of *2 splitting is the right choice.
> 

I think this is horribly confusing.  It at least is consistent if you
require a multiplier on the index operand.  What we *obviously* cannot
break is [nosplit eax*1] ... that must work and produce a SIB.  The
unadorned thing I fear is confusing as hell.

If we do the sane thing, we could perhaps also make split/nosplit
permitted DEFAULT options.

	-hpa

Re: [Nasm-devel] [nasm:master] nosplit: Limit the effect of NOSPLIT

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

> [nosplit eax+eax] was encoded [eax*2] previously but
> this seems against the user's intention.

Actually, it is intentional/expected behavior.

> So in this case, nosplit is ignored now and [eax+eax] will be generated.

See my other reply to Peter for more detail.

Re: [Nasm-devel] [nasm:master] nosplit: Generate index-only EA only when a multiplier is used.

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

> nosplit: Generate index-only EA only when a multiplier is used.
>
> [nosplit eax] has been encoded as [eax*1+0] since 0.98.34.
> But this seems like unexpected behavior.

Actually, it is intentional/expected behavior.

> So only when a register is multiplied, that will be treated
> as an index. ([nosplit eax*1] -> [eax*1+0])

See my other reply to Peter for more detail.

Re: [Nasm-devel] [nasm:master] mib: Handle MIB EA in a different way from regular EA's

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

>> NOSPLIT specifier does not have an effect in mib, so [nosplit eax + eax*1]
>> will be encoded as [eax, eax] rather than [eax*2] as in a regular EA.
>
> I'm wondering if we shouldn't make NOSPLIT because exactly like this; I
> would think [nosplit eax + eax*1] should generate a base eax and index
> eax*1.  Anyone who would disagree with that opinion?

See the reply I just sent to your other message.

Re: [Nasm-devel] [nosplit eax]

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

> Apparently [nosplit eax] is treated as if it was [nosplit eax*1], which
> was a deliberate patch introduced by Debbie in 0.98.34.  This is rather
> unexpected behavior, and I would really like to change it so that
> nosplit means "the term with the multiplication is the index".  This is
> a change, but does anyone anticipate a problem with doing this?

tl;dr = keep NOSPLIT unchanged, but prevent *2 opt with MPX

Historically NASM's goal has always been to emit the shortest
possible encoding. As a result, (nobase+)reg(*1) becomes just
reg (which does emit a sib-less encoding), and (nobase+)reg*2
becomes reg+reg*1 (which does emit a disp-less sib encoding
rather than a sib encoding with a signed dword disp). To give a
user the ability to emit the longer encodings when desired, the
NOSPLIT qualifier was added. Initially it only handled the case
of *2 (and that is documented) but eventually support for *1 got
added as well (but apparently not documented properly). Under

  http://sourceforge.net/p/nasm/feature-requests/5/

you can see the original feature request. From me, actually.  :)

That said, NOSPLIT is working as intended (though the *1 case
ought to be documented). Please refrain from breaking it, since
that will break existing code. Likewise, please don't change the
existing reg*1 or reg*2 behavior, i.e. don't suddenly interpret an
explicit *1 or *2 as a request for a longer encoding -- since that
too will break existing code.

In terms of BNDMK, BNDLDX, and BNDSTX, the [reg] case as
well as the [NOSPLIT reg] case are fine. The [NOSPLIT reg*2]
case is fine as well (though BNDLDX and BNDSTX now need a
warning for the resulting scale=2); however, the [reg*2] case is
of course problematic since NASM turns it into [reg+reg] which
has a base that the user did not specify. Since MPX is new, it
looks like disabling that case of *2 splitting is the right choice.

[Nasm-devel] [nosplit eax]

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

Apparently [nosplit eax] is treated as if it was [nosplit eax*1], which
was a deliberate patch introduced by Debbie in 0.98.34.  This is rather
unexpected behavior, and I would really like to change it so that
nosplit means "the term with the multiplication is the index".  This is
a change, but does anyone anticipate a problem with doing this?

	-hpa