DOS ain't dead

rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) (Developers)

posted by Rugxulo , Usono, 17.03.2020, 05:20

> "Invalid opcode" comes from the CPU treating data as code, as you probably
> know.
> Does it happen under "all" memory configurations, i.e., w/o JEMM386?

I always run XMS only these days, so it's not due to EMM386.

> Does it occur if you only remove anything after line 1166 ("Katmai"...)?

Actually, the newer, bloated SIMD stuff starts earlier than that in the file. It's not grouped properly, apparently unsorted.

But, no, I found the problem, a simple error on my part. I forgot to also include "ignore" (pseudo-instructions, e.g. EQU or DW) in my trimmed version.

So it works (after running DJGPP Perl four times to regenerate some sources). I doubt it saved too much actual runtime memory, but the .EXE itself saved 30k (or 6 kb UPX'd), which is seemingly not much. And it runs okay (reassembles INVADERS.COM correctly).

It still didn't fit into Large model (like OpenWatcom), though, but if I exclude "PENT" entirely (which also includes MMX and 3DNOW for later 586s), then it fits into Large model okay. So then it's roughly 50 kb smaller than the "full" .EXE. But it only saves 9 kb UPX'd.

In other words, I'm sure it helps some, but it's maybe not as much as I expected. Saving 50 kb while WmakeR uses 150 kb is probably not enough (for that nonsensical problem, already worked around elsewhere).

So, long story short, I need to rebuild twice and upload those for us: 1). 586/MMX/3DNOW only (no 686 or SSE), 2). 486 (or early 586, e.g. CPUID, but no MMX/3DNOW) only (Large model, is it noticeably faster??). Hmmm, maybe 286 only would be interesting, for comparison (like A86).

But I want to avoid relying on Perl at all, so I need to find a shortcut to trim the pre-existing generated (included) insns*.[ch] files (awk? sed? homegrown tool again?).

P.S. Does anyone know if -O9 will forcibly run nine passes or only those passes needed (e.g. three)? I could be wrong, but I think it does all nine! Inefficient, but maybe it doesn't (or can't) know. Though some assemblers can figure it out (if nothing changed in previous pass then exit?). Maybe that's why -O9v tells you (kinda) how many it took, so you can only run as many as needed next time? Not sure.

Complete thread:

• rebuilding NASM 0.98.39 (2005) for 16-bit 8086 host - Rugxulo, 14.03.2020, 08:13 (Developers)
  • rebuilding NASM 0.98.39 (2005) for 16-bit 8086 host - Rugxulo, 16.03.2020, 01:24
    • rebuilding NASM 0.98.39 (2005) for 16-bit 8086 host - rr, 16.03.2020, 15:22
      • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - Rugxulo, 17.03.2020, 05:20
        • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - ecm, 17.03.2020, 06:58
          • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - Rugxulo, 22.03.2020, 00:48
            • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - ecm, 22.03.2020, 10:13
              • rebuilding NASM 2.09 and NASM compatibility - ecm, 22.03.2020, 11:45
            • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - ecm, 06.09.2020, 23:09
        • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - Rugxulo, 22.03.2020, 00:42
          • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - marcov, 22.03.2020, 13:08
            • CMOV - ecm, 22.03.2020, 14:26
              • CMOV - marcov, 22.03.2020, 18:32
                • CMOV - marcov, 23.03.2020, 12:52
            • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - Rugxulo, 23.03.2020, 04:27
              • NASM 0.98.39 (MSC 7, "286", not full instruction support) - Rugxulo, 24.03.2020, 20:36
                • NASM 0.98.39 (not full instruction support) - Rugxulo, 24.03.2020, 21:16
                  • NASM 0.98.39 (not full instruction support) - ecm, 24.03.2020, 22:55
                    • NASM 0.98.39 (not full instruction support) - Rugxulo, 24.03.2020, 23:17
                  • NASM 0.98.39 (not full instruction support) ... LOADALL - Rugxulo, 31.03.2020, 20:07
              • rebuilding NASM 0.98.39 (without MMX/3DNOW/686/SSE) - Rugxulo, 13.04.2020, 07:16
            • deprecated MMX and obsolete 3DNow! - Rugxulo, 24.03.2020, 17:54