We are migrating the bug tracker to github Issues. This is now the preferred way to report NASM bugs.

Self-registration is disabled due to spam issue (mail gorcunov@gmail.com or hpa@zytor.com to create an account)

Bug 3392958 - cpu 386 [bits 16] fails to assemble o32 instructions?
Summary: cpu 386 [bits 16] fails to assemble o32 instructions?
Status: CLOSED FIXED
Alias: None
Product: NASM
Classification: Unclassified
Component: Assembler (show other bugs)
Version: 3.00.xx
Hardware: All All
: Medium blocker
Assignee: nobody
URL:
Depends on:
Blocks:
 
Reported: 2025-09-19 14:48 PDT by E. C. Masloch
Modified: 2025-09-21 11:25 PDT (History)
5 users (show)

Obtained from: Built from git using configure
Generated by: Human
Bug category: Incorrect main output, Invalid main output, Missing or incorrect instruction or opcode
Observed for: Production code
Regression: Yes (specify version below)
Regression since:
As of about 2 weeks ago


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description E. C. Masloch 2025-09-19 14:48:54 PDT
test$ cat test.asm

        cpu 386
MULTIBOOT_TARGET_SEGMENT equ 200h

[bits 16]
        mov eax, cr0
        dec ax
        mov cr0, eax                            ; clear PE bit

        jmp dword MULTIBOOT_TARGET_SEGMENT:.rm  ; reload cs

.rm:
test$ nasm -v
NASM version 2.16.02rc2 compiled on Oct 12 2023
test$ nasm test.asm
test$ ~/proj/nasmtest/rc/nasm -v
NASM version 3.00rc9 compiled on Sep 19 2025
test$ ~/proj/nasmtest/rc/nasm test.asm
test.asm:6: error: no instruction for this cpu level
test.asm:8: error: no instruction for this cpu level
test.asm:10: error: invalid operand sizes for instruction
test$
Comment 1 H. Peter Anvin 2025-09-19 16:29:17 PDT
Fixes (multiple!) checked in. Will be in 3.00rc10.
Comment 2 E. C. Masloch 2025-09-19 16:46:23 PDT
Mostly fixed now, lDOS kernel file builds to completion again. However, there is one encoding choice difference:

467 00000F47 66F3AB              <1>         rep stosd

The order of the prefixes changed. This isn't a problem in this case, but there could be use cases where users expect the prior order.

I do depend on the order in one spot in my debugger, but in that case I specify the prefixes one per line instead: https://hg.pushbx.org/ecm/ldebug/file/4f02cbb2493b/source/uu.asm#l2144
Comment 3 H. Peter Anvin 2025-09-21 11:25:44 PDT
Prefix order is not something that is guaranteed to be stable. Depending on various internal changes, they can end up changing and have done so before.

The solution, as you have seen, is to explicitly issue the prefixes as "instructions". This has different semantics - it does not affect NASM's instruction composition at all; it is, in essence, like "db".

This also means that a legacy prefix, like REP, before, say, a VEX instruction will be encoded as a raw byte (which is illegal) as opposed to setting the VEX.pp field.