nasm-devel — NASM development work

[Nasm-devel] Bugzilla doesn't work, "File not found"

[C. M. <pu...@38...>]

Hi, the bugzilla bug entry page seems to be broken. My browser (Firefox
52.9.0 on Debian testing amd64) replies with this error message upon
clicking "Submit Bug" on https://bugzilla.nasm.us/enter_bug.cgi

> File not found
>
> Firefox can't find the file at https://bugzilla.nasm.us/post_bug.cgi.
>
> Check the file name for capitalisation or other typing errors.
> Check to see if the file was moved, renamed or deleted.

Regards,
ecm

Re: [Nasm-devel] [PATCH] Fix undefined behavior when shifting left by 32 bits

[Michael B. <mj...@go...>]

On Wed, Nov 21, 2018 at 11:25 AM Debbie Wiles <deb...@ho...>
wrote:

> There is a small amount of code for 808x CPUs that relies on the undefined
> features.
>

Can you help clarify how this patch would break them? I'm happy to revise
it, but it's unclear to me how this patch is problematic.

Re: [Nasm-devel] [PATCH] Fix undefined behavior when shifting left by 32 bits

[Debbie W. <deb...@ho...>]

There is a small amount of code for 808x CPUs that relies on the undefined features.

________________________________
From: Michael Bradshaw via Nasm-devel <nas...@li...>
Sent: 21 November 2018 19:18
To: nas...@li...
Subject: [Nasm-devel] [PATCH] Fix undefined behavior when shifting left by 32 bits

Hi,

Attached patch fixes issue 3392368 (see [1]), where a left shift results in undefined behavior.

Please review. This is my first patch submission to nasm, so if I'm going about this incorrectly, please let me know.

Thanks,

--Michael

[1]: https://bugzilla.nasm.us/show_bug.cgi?id=3392368

[Nasm-devel] [PATCH] Fix undefined behavior when shifting left by 32 bits

[Michael B. <mj...@go...>]

Hi,

Attached patch fixes issue 3392368 (see [1]), where a left shift results in
undefined behavior.

Please review. This is my first patch submission to nasm, so if I'm going
about this incorrectly, please let me know.

Thanks,

--Michael

[1]: https://bugzilla.nasm.us/show_bug.cgi?id=3392368

[Nasm-devel] [PATCH] preproc: Pass include paths as strlist

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

Instead of copying data just reuse already
allocated paths.

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---

Something like below?

 asm/nasm.c        | 13 +++----------
 asm/preproc-nop.c |  4 ++--
 asm/preproc.c     | 17 ++++++++---------
 include/nasm.h    |  2 +-
 4 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/asm/nasm.c b/asm/nasm.c
index 95938ee4..2dd8cbc0 100644
--- a/asm/nasm.c
+++ b/asm/nasm.c
@@ -328,18 +328,11 @@ static void define_macros(void)
  * Command-line specified preprocessor directives (-p, -d, -u,
  * --pragma, --before) are processed after this function.
  */
-static void preproc_init(struct strlist **ipath)
+static void preproc_init(struct strlist *ipath)
 {
-    struct strlist_entry *l;
-
     preproc->init();
     define_macros();
-
-    list_for_each(l, (*ipath)->head)
-        preproc->include_path(l->str);
-
-    strlist_free(*ipath);
-    *ipath = strlist_alloc();
+    preproc->include_path(ipath);
 }
 
 static void emit_dependencies(struct strlist *list)
@@ -503,7 +496,7 @@ int main(int argc, char **argv)
         }
     }
 
-    preproc_init(&include_path);
+    preproc_init(include_path);
 
     parse_cmdline(argc, argv, 2);
     if (terminate_after_phase) {
diff --git a/asm/preproc-nop.c b/asm/preproc-nop.c
index 90f18e60..655eff7f 100644
--- a/asm/preproc-nop.c
+++ b/asm/preproc-nop.c
@@ -170,9 +170,9 @@ static void nop_pre_command(const char *what, char *string)
     (void)string;
 }
 
-static void nop_include_path(const char *path)
+static void nop_include_path(struct strlist *list)
 {
-    (void)path;
+    (void)list;
 }
 
 static void nop_error_list_macros(int severity)
diff --git a/asm/preproc.c b/asm/preproc.c
index 3d54c075..f672d0e2 100644
--- a/asm/preproc.c
+++ b/asm/preproc.c
@@ -386,7 +386,7 @@ static int LocalOffset = 0;
 
 static Context *cstk;
 static Include *istk;
-static struct strlist *ipath;
+static const struct strlist *ipath_list;
 
 static int pass;            /* HACK: pass 0 = generate dependencies only */
 static struct strlist *deplist;
@@ -1501,12 +1501,15 @@ enum incopen_mode {
 static FILE *inc_fopen_search(const char *file, char **slpath,
                               enum incopen_mode omode, enum file_flags fmode)
 {
+    const struct strlist_entry *ip = NULL;
     FILE *fp;
     const char *prefix = "";
-    const struct strlist_entry *ip = ipath->head;
     char *sp;
     bool found;
 
+    if (ipath_list)
+        ip = ipath_list->head;
+
     while (1) {
         sp = nasm_catfile(prefix, file);
         if (omode == INC_PROBE) {
@@ -4993,7 +4996,6 @@ pp_reset(const char *file, int apass, struct strlist *dep_list)
 static void pp_init(void)
 {
     hash_init(&FileHash, HASH_MEDIUM);
-    ipath = strlist_alloc();
 }
 
 static char *pp_getline(void)
@@ -5261,16 +5263,13 @@ static void pp_cleanup(int pass)
         predef = NULL;
         delete_Blocks();
         freeTokens = NULL;
-        strlist_free(ipath);
+        ipath_list = NULL;
     }
 }
 
-static void pp_include_path(const char *path)
+static void pp_include_path(struct strlist *list)
 {
-    if (!path)
-        path = "";
-
-    strlist_add(ipath, path);
+	ipath_list = list;
 }
 
 static void pp_pre_include(char *fname)
diff --git a/include/nasm.h b/include/nasm.h
index a6ff11ce..ebbf6c44 100644
--- a/include/nasm.h
+++ b/include/nasm.h
@@ -362,7 +362,7 @@ struct preproc_ops {
     void (*pre_command)(const char *what, char *str);
 
     /* Include path from command line */
-    void (*include_path)(const char *path);
+    void (*include_path)(struct strlist *ipath);
 
     /* Unwind the macro stack when printing an error message */
     void (*error_list_macros)(int severity);
-- 
2.17.2

Re: [Nasm-devel] Translation

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

On Mon, Oct 01, 2018 at 02:57:14PM +0300, Michael Proshchuk wrote:
> Thanks for the feedback! I am very glad that you support me in something.
> If you change your mind, I will always be ready to help.

Definitely! Thank you!

Re: [Nasm-devel] Translation

[Michael P. <mik...@gm...>]

Thanks for the feedback! I am very glad that you support me in something.
If you change your mind, I will always be ready to help.

пн, 1 жовт. 2018 о 00:15 Cyrill Gorcunov <gor...@gm...> пише:

> On Sun, Sep 30, 2018 at 09:58:29PM +0300, Michael Proshchuk wrote:
> >    Hello!
> >    I want to translate into Ukrainian all static text on your site. I
> want to
> >    make Ukrainian localization of the site. Hope you too :)
> >    Best wishes, Michael Proshchuk.
>
> Hi Michael! Thanks a lot for proposal! You know I think it is doable,
> surely it would be great to have a multilanguage support on the site
> but I fear we won't have enough manpower to support translations in
> future, while there are always people with more/less good knowledge
> of english language.
>

Re: [Nasm-devel] Translation

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

On Sun, Sep 30, 2018 at 09:58:29PM +0300, Michael Proshchuk wrote:
>    Hello!
>    I want to translate into Ukrainian all static text on your site. I want to
>    make Ukrainian localization of the site. Hope you too :)
>    Best wishes, Michael Proshchuk.

Hi Michael! Thanks a lot for proposal! You know I think it is doable,
surely it would be great to have a multilanguage support on the site
but I fear we won't have enough manpower to support translations in
future, while there are always people with more/less good knowledge
of english language.

[Nasm-devel] Translation

[Michael P. <mik...@gm...>]

Hello!
I want to translate into Ukrainian all static text on your site. I want to
make Ukrainian localization of the site. Hope you too :)

Best wishes, Michael Proshchuk.

Re: [Nasm-devel] building outside the source directory

[Ed B. <be...@mi...>]

On 08/29/2018 06:11 AM, Ruslan Kabatsayev wrote:

> You seem to confuse "configure" script and autogen.sh/autoreconf. The
> former indeed should work correctly regardless of $PWD. 

I'm not confused at all, but maybe my description was not sufficiently 
clear.  I agree that it's the configure script and not autoconf or 
autoreconf that should work regardless of $PWD and agree with the rest 
of your description as well.

It might be nice to be able to do that trick with autoreconf as well, 
but if that's possible, I don't know how to do it.  As you correctly 
point out, the "configure" script is typically something that we 
developers generate (and check in to the repository), but that someone 
building from source would simply run.

Ed

Re: [Nasm-devel] building outside the source directory

[Ruslan K. <b7....@gm...>]

Hi Ed,

On Wed, 29 Aug 2018 at 05:34, Ed Beroset <be...@mi...> wrote:
>
> On 08/28/2018 03:24 PM, Cyrill Gorcunov wrote:
> > On Tue, Aug 28, 2018 at 01:52:43PM -0400, Ed Beroset wrote:
> >> Today, for the first time in a long time, I refreshed my local copy of the
> >> NASM repo and tried to do a built outside the source directory, as is my
> >> usual practice.  It failed.
> >>
> >> Specifically, if you clone the source into a fresh new directory "nasm" and
> >> then create and navigate into "nasm/build" I would expect the following
> >> steps to successfully do a build:
> >>
> >> autoreconf .. -i
> >> ../configure
> >> make
> >>
> >> However it fails because of the generated file pptok.sh
> >>
> >> I believe I can fix this, but before I expend the effort to do so, I wanted
> >> ask some questions:
> >>
> >> 1. can you reproduce this problem?
> >> 2. do you agree it should be fixed?
> >>
> >> Thanks.
> >
> > Hi Ed! Why did you enter nasm/build? Usually I personally run ./autogen.sh
> > from root source directory. Would it work for you?
>
> Hi Cyrill,
>
> Yes, it works from the root source directory, but only from there.  One
> of the features of autotools is that it's supposed to allow one to run
> "configure" from anywhere and build successfully.  One reason for doing
> that is that it keeps the source tree (mostly) free of build artifacts.

You seem to confuse "configure" script and autogen.sh/autoreconf. The
former indeed should work correctly regardless of $PWD. But the latter
ones actually create the configure script, and normally it's
distributed in the source release tarball, already generated (unlike
git repo). So I don't think autoreconf is something one needs to work
from outside the source tree. The workflow should be something like:

autoreconf -i # NOTE: once!
cd /path/to/build/dir
/source/dir/configure --options...
make
cd /path/to/another/build/dir
/source/dir/configure --other-options...
make

>
> Another common use of this feature is to create both release and debug
> versions (in two separate locations) from the same source.  See
> https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html
> for example.
>
> Ed
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-devel

Re: [Nasm-devel] building outside the source directory

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

On Tue, Aug 28, 2018 at 10:33:52PM -0400, Ed Beroset wrote:
> On 08/28/2018 03:24 PM, Cyrill Gorcunov wrote:
> > On Tue, Aug 28, 2018 at 01:52:43PM -0400, Ed Beroset wrote:
> > > Today, for the first time in a long time, I refreshed my local copy of the
> > > NASM repo and tried to do a built outside the source directory, as is my
> > > usual practice.  It failed.
> > > 
> > > Specifically, if you clone the source into a fresh new directory "nasm" and
> > > then create and navigate into "nasm/build" I would expect the following
> > > steps to successfully do a build:
> > > 
> > > autoreconf .. -i
> > > ../configure
> > > make
> > > 
> > > However it fails because of the generated file pptok.sh
> > > 
> > > I believe I can fix this, but before I expend the effort to do so, I wanted
> > > ask some questions:
> > > 
> > > 1. can you reproduce this problem?
> > > 2. do you agree it should be fixed?
> > > 
> > > Thanks.
> > 
> > Hi Ed! Why did you enter nasm/build? Usually I personally run ./autogen.sh
> > from root source directory. Would it work for you?
> 
> Hi Cyrill,
> 
> Yes, it works from the root source directory, but only from there.  One of
> the features of autotools is that it's supposed to allow one to run
> "configure" from anywhere and build successfully.  One reason for doing that
> is that it keeps the source tree (mostly) free of build artifacts.
> 
> Another common use of this feature is to create both release and debug
> versions (in two separate locations) from the same source.  See
> https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html for
> example.

Ah! To be fair, never used this feature of autotools. If so then yes, it
is a bug and should be fixed.

Re: [Nasm-devel] building outside the source directory

[Ed B. <be...@mi...>]

On 08/28/2018 03:24 PM, Cyrill Gorcunov wrote:
> On Tue, Aug 28, 2018 at 01:52:43PM -0400, Ed Beroset wrote:
>> Today, for the first time in a long time, I refreshed my local copy of the
>> NASM repo and tried to do a built outside the source directory, as is my
>> usual practice.  It failed.
>>
>> Specifically, if you clone the source into a fresh new directory "nasm" and
>> then create and navigate into "nasm/build" I would expect the following
>> steps to successfully do a build:
>>
>> autoreconf .. -i
>> ../configure
>> make
>>
>> However it fails because of the generated file pptok.sh
>>
>> I believe I can fix this, but before I expend the effort to do so, I wanted
>> ask some questions:
>>
>> 1. can you reproduce this problem?
>> 2. do you agree it should be fixed?
>>
>> Thanks.
> 
> Hi Ed! Why did you enter nasm/build? Usually I personally run ./autogen.sh
> from root source directory. Would it work for you?

Hi Cyrill,

Yes, it works from the root source directory, but only from there.  One 
of the features of autotools is that it's supposed to allow one to run 
"configure" from anywhere and build successfully.  One reason for doing 
that is that it keeps the source tree (mostly) free of build artifacts.

Another common use of this feature is to create both release and debug 
versions (in two separate locations) from the same source.  See 
https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html 
for example.

Ed

Re: [Nasm-devel] building outside the source directory

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

On Tue, Aug 28, 2018 at 01:52:43PM -0400, Ed Beroset wrote:
> Today, for the first time in a long time, I refreshed my local copy of the
> NASM repo and tried to do a built outside the source directory, as is my
> usual practice.  It failed.
> 
> Specifically, if you clone the source into a fresh new directory "nasm" and
> then create and navigate into "nasm/build" I would expect the following
> steps to successfully do a build:
> 
> autoreconf .. -i
> ../configure
> make
> 
> However it fails because of the generated file pptok.sh
> 
> I believe I can fix this, but before I expend the effort to do so, I wanted
> ask some questions:
> 
> 1. can you reproduce this problem?
> 2. do you agree it should be fixed?
> 
> Thanks.

Hi Ed! Why did you enter nasm/build? Usually I personally run ./autogen.sh
from root source directory. Would it work for you?

Re: [Nasm-devel] building outside the source directory

[Ed B. <be...@mi...>]

On 08/28/2018 02:20 PM, Taylor Holberton wrote:
> 
> I'm not a nasm developer but I made a CMake build system for nasm that 
> builds out of source just fine. It's on GitHub.
> 
> https://github.com/riscv/riscv-nasm
> 
> It's on the refactoring branch.

I'm a big fan of CMake and tried out your patch in April when you posted 
it to the list, so thank you for that!  I look forward to collaborating 
with you on improving that, too (adding ndisasm, and packaging for 
Windows, building and installing docs, etc.)

Meanwhile, I thought I'd also work on the current autotools version but 
would very happily abandon it in favor of the CMake version if that's 
the direction we collectively choose.

Another project I've worked on (Wireshark) currently maintains both an 
autotools *and* a CMake version, so that's certainly possible as well.

Ed

Re: [Nasm-devel] building outside the source directory

[Taylor H. <tay...@gm...>]

Hi,

I'm not a nasm developer but I made a CMake build system for nasm that
builds out of source just fine. It's on GitHub.

https://github.com/riscv/riscv-nasm

It's on the refactoring branch.

On Tue, Aug 28, 2018, 13:53 Ed Beroset <be...@mi...> wrote:

> Today, for the first time in a long time, I refreshed my local copy of
> the NASM repo and tried to do a built outside the source directory, as
> is my usual practice.  It failed.
>
> Specifically, if you clone the source into a fresh new directory "nasm"
> and then create and navigate into "nasm/build" I would expect the
> following steps to successfully do a build:
>
> autoreconf .. -i
> ../configure
> make
>
> However it fails because of the generated file pptok.sh
>
> I believe I can fix this, but before I expend the effort to do so, I
> wanted ask some questions:
>
> 1. can you reproduce this problem?
> 2. do you agree it should be fixed?
>
> Thanks.
>
> Ed
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Nasm-devel mailing list
> Nas...@li...
> https://lists.sourceforge.net/lists/listinfo/nasm-devel
>

[Nasm-devel] building outside the source directory

[Ed B. <be...@mi...>]

Today, for the first time in a long time, I refreshed my local copy of 
the NASM repo and tried to do a built outside the source directory, as 
is my usual practice.  It failed.

Specifically, if you clone the source into a fresh new directory "nasm" 
and then create and navigate into "nasm/build" I would expect the 
following steps to successfully do a build:

autoreconf .. -i
../configure
make

However it fails because of the generated file pptok.sh

I believe I can fix this, but before I expend the effort to do so, I 
wanted ask some questions:

1. can you reproduce this problem?
2. do you agree it should be fixed?

Thanks.

Ed

Re: [Nasm-devel] nasm-2.14rc5 gives error where nasm-2.13.03 doesn't

[<bal...@un...>]

> Sorry for delay. I finally spotted the bad commit
> (98578071b9d71ecaa2344dd9c185237c1765041e).
> Gonna figure out what exactly is happening. Thanks again for report!

if this can be of interest: in 2.14rc14 the problem I reported seems to
be fixed (the test script I sent completes successfully). (note that
2.14rc{5,7,10,11} all fail)

ciao
-g

Re: [Nasm-devel] nasm-2.14rc5 gives error where nasm-2.13.03 doesn't

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

On Sun, Jun 17, 2018 at 7:19 PM Cyrill Gorcunov <gor...@gm...> wrote:
>
> On Sun, Jun 17, 2018 at 05:43:26PM +0200, bal...@un... wrote:
> > hello
> >
> > I don't know if this is actually a problem with nasm or ffmpeg: so
> > apologies if I am reporting to the wrong list
> >
> > The problem is with the current nasm rc version 2.14rc5 (so something
> > which is still to be officially released); I'm sending this just as a
> > possible heads up for the nasm developers...
> >
> > While building the latest official ffmpeg release (ffmpeg-4.0.1),
> > using nasm-2.14rc5 I get:
> >
>
> Thanks a lot for report! Better to file a bug of course but I'll
> take a look on the week.

Sorry for delay. I finally spotted the bad commit
(98578071b9d71ecaa2344dd9c185237c1765041e).
Gonna figure out what exactly is happening. Thanks again for report!

Re: [Nasm-devel] Risc-v Port

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

On Fri, Jun 22, 2018 at 8:19 PM Taylor Holberton
<tay...@gm...> wrote:
>
> Hello!
>
> I am writing you to give you the pleasure of knowing that you were right in saying that porting nasm to support another architecture would be a lot of work.
>
> Too much work.
>
> It looks like the assembler just wasn't built from the start to support more than a single architecture. Aside from that, the code is just too difficult to follow. Like many of the older C projects I've seen, there are just too many abbreviations, long winded functions, and larger than preferred files. I will say, though, that the documentation was a little helpful.
>
> Thank you for your replies and answering my questions.

Hi! Indeed it is quite a task. And as far as I know we never been
planning to support other archs that's why code structure is so
coupled with x86.

[Nasm-devel] Risc-v Port

[Taylor H. <tay...@gm...>]

Hello!

I am writing you to give you the pleasure of knowing that you were right in
saying that porting nasm to support another architecture would be a lot of
work.

Too much work.

It looks like the assembler just wasn't built from the start to support
more than a single architecture. Aside from that, the code is just too
difficult to follow. Like many of the older C projects I've seen, there are
just too many abbreviations, long winded functions, and larger than
preferred files. I will say, though, that the documentation was a little
helpful.

Thank you for your replies and answering my questions.

Re: [Nasm-devel] nasm-2.14rc5 gives error where nasm-2.13.03 doesn't

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

On Sun, Jun 17, 2018 at 05:43:26PM +0200, bal...@un... wrote:
> hello
> 
> I don't know if this is actually a problem with nasm or ffmpeg: so
> apologies if I am reporting to the wrong list
> 
> The problem is with the current nasm rc version 2.14rc5 (so something
> which is still to be officially released); I'm sending this just as a
> possible heads up for the nasm developers...
> 
> While building the latest official ffmpeg release (ffmpeg-4.0.1),
> using nasm-2.14rc5 I get:
>

Thanks a lot for report! Better to file a bug of course but I'll
take a look on the week. 

[Nasm-devel] nasm-2.14rc5 gives error where nasm-2.13.03 doesn't

[<bal...@un...>]

hello

I don't know if this is actually a problem with nasm or ffmpeg: so
apologies if I am reporting to the wrong list

The problem is with the current nasm rc version 2.14rc5 (so something
which is still to be officially released); I'm sending this just as a
possible heads up for the nasm developers...

While building the latest official ffmpeg release (ffmpeg-4.0.1),
using nasm-2.14rc5 I get:

----8<----
nasm -f elf64 -DPIC -g -F dwarf -I./ -I.// -Ilibavcodec/x86/ -Pconfig.asm -MD libavcodec/x86/h264_deblock.d  -o libavcodec/x86/h264_deblock.o libavcodec/x86/h264_deblock.asm
libavcodec/x86/h264_deblock.asm:1392: error: symbol `ff_h264_loop_filter_strength_mmxext.bidir' undefined
libavutil/x86/x86inc.asm:683: ... from macro `jne' defined here
libavcodec/x86/h264_deblock.asm:1392: warning: label `..@12237.branch_instr' changed during code generation

[...a bunch of similar warnings...]

---->8----

OTOH, no problem whatsoever if I use nasm-2.13.03

(Both nasm-2.14rc5 and nasm-2.13.03 built from source with:

--prefix=/opt/stow.d/versions/nasm-${version}/usr
--libdir=/opt/stow.d/versions/nasm-${version}/usr/lib64
--infodir=/opt/stow.d/versions/nasm-${version}/usr/share/info

)

Here is a scriptlett which you can edit/use to reproduce the problem:

----8<----
#!/bin/sh
mkdir -p /tmp/ffmpeg-test  # create a sandbox
cd /tmp/ffmpeg-test
rm -f ./ffmpeg-4.0.1.tar.bz2
# get the ffmpeg tarball
wget http://ffmpeg.org/releases/ffmpeg-4.0.1.tar.bz2
rm -rf ./ffmpeg-4.0.1
# unpack
tar axf ffmpeg-4.0.1.tar.bz2
cd ffmpeg-4.0.1
set -x      # some verbosity
./configure # use defaults

######################################################
# this fails for 2.14rc5 while succeeds for 2.13.03. #
######################################################
nasm -f elf64 -DPIC -g -F dwarf -I./ -I.// -Ilibavcodec/x86/ \
     -Pconfig.asm -MD libavcodec/x86/h264_deblock.d  \
     -o libavcodec/x86/h264_deblock.o libavcodec/x86/h264_deblock.asm
# see which nasm is in use
nasm --version
---->8----

Apologies if this report is inappropriate

ciao
gabriele

Re: [Nasm-devel] NASM 2.14rc3

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

On Thu, Jun 14, 2018 at 05:25:16PM -0700, H. Peter Anvin wrote:
> Hi,
> 
> I have just pushed out NASM 2.14rc3.  I discovered that the subsection
> support that I had originally implemented it broke a bunch of other
> things.  After messing around with it for a while, I came up with a far
> better implementation, which should also provide significant performance
> improvements for the MachO backend when there are a lot of sections.

Great! Thanks, Peter!

> I have released this as NASM 2.14rc3.  Any and all help testing would be
> appreciated.
> 
> I have branched off nasm-2.14.xx as a new release branch; this is now
> officially release track and should not have any further development
> changes.

[Nasm-devel] RFC: operator precedence question, for <=> operator in NASM

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

While looking into implementing the <=> operator [1] [2], I ended
up re-visiting the long-standing operator precedence differences
between NASM and C.

In particular, NASM lumps relational and equality operators while
C keeps them separate [3], and NASM implements bitwise AND/
OR/XOR above relational and equality operators while C handles
them below those [4].

These differences go back all the way to NASM 0.96, when eval.c
was separated from parser.c, and the bitwise AND/OR/XOR were
actually introduced.

For [3] I have been using a NASM patch for many years -- it splits
relational and equality operators by default (a la C) but provides a
command line option for lumping them back together (for the sake
of NASM compatibility).

For [4] I did not end up with a NASM patch (to move bitwise AND/
OR/XOR below relational and equality, a la C) -- my decision back
then was driven by [5].

Alright, enough history -- back to <=> i.e. the issue at hand.  :)

For C the <=> operator's precedence seems to be heading toward
below bitwise shifts but above relational. Which is where NASM is
currently having bitwise AND/OR/XOR. Which in turn does require
a decision on whether <=> should go above or below bitwise AND/
OR/XOR for NASM.

And while the precedence of bitwise AND/OR/XOR in NASM could
be changed (to match the one in C), doing so without an option for
reverting to traditional NASM behavior (similar to what I did for the
splitting/lumping of relational and equality) seems risky. With such
an option, the precedence question -- of <=> versus bitwise AND/
OR/XOR -- remains.

Given where C seems to be heading, placing <=> *above* bitwise
AND/OR/XOR striks me as the right choice. It not only follows C's
precedence (pun intended :), but it also allows for NASM's bitwise
AND/OR/XOR to be moved in the future (to match C).

Comments?

[1] https://en.wikipedia.org/wiki/Three-way_comparison
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf
[3] https://sourceforge.net/p/nasm/bugs/103/
[4] https://sourceforge.net/p/nasm/bugs/107/
[5] http://www.lysator.liu.se/c/dmr-on-or.html