[Nasm-bugs] [Bug 3392656] "mov fs, ax" does not cause error when "cpu 8086" is in effect

noreply-nasm at dev.nasm.us noreply-nasm at dev.nasm.us
Tue Oct 13 10:51:11 PDT 2020


https://bugzilla.nasm.us/show_bug.cgi?id=3392656

C. Masloch <pushbx at ulukai.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pushbx at ulukai.org

--- Comment #2 from C. Masloch <pushbx at ulukai.org> ---
Concerning o32 and a32 I just suspected I may have depended on that being
allowed under cpu 8086 in my application (86-DOS debugger).

Looking it up it turns out half and half; my default build does not seem to
exploit this. All the o32/a32 prefixes end up going through the _386 mmacro
defined in
https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/debug.mac#l674 which
already uses [cpu 386] around the instructions/prefixes it writes. Example use:
https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/run.asm#l72

However, when I enabled the alternative macro set later named _WPT_LABELS, I
did depend on the bare o32 and a32 being allowed in cpu 8086 parts. Source
reference:
https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/debug.mac#l565 I'm
certain that NASM in recent years allowed this because I had that option def
enabled as recently as 2019 May during development of the data-code-split
branch https://hg.ulukai.org/ecm/ldebug/rev/cb7c43f37390 However, it would not
be difficult to adjust this to also always surround the offending prefixes with
[cpu 386] directives. _WPT_LABELS is severely slower than the alternative
anyway, so it doesn't matter to make it yet a bit slower.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.


More information about the Nasm-bugs mailing list