Instruction mov cx, al accepted incorrectly

Came up on stackoverflow here: https://stackoverflow.com/questions/79171410/how-to-print-a-symbol-for-a-user-provided-number-of-times-in-dos-assembly-x86

Quoting the comments:

mov cx,al should not even assemble. – Jester Commented 2 hours ago @Jester thank you, but I'm not sure; my textbook doesn't mention that. I mean, both ax and cl are general-purpose registers, so I don't see why it shouldn't assemble. – utobi Commented 2 hours ago 1 @Jester Unlike lDebug the original MS-DOS Debug (or MSDebug) accepts many invalid assembler instructions and will render them in unpredictable ways. – ecm Commented 2 hours ago Delete 3 My guess is your assembler silently changes mov cx, al (which is invalid) into mov cx, ax but given that ah = 2 you will print 512 extra characters. Do xor cx, cx; mov cl, al instead (or if your cpu supports it movzx cx, al). – Jester Commented 2 hours ago 1 @utobi: mov requires both its operands to be the same size. felixcloutier.com/x86/mov . CX is 16-bit, AL is 8-bit. Use movzx cx, al if you can use 386 new instructions, otherwise xor cx,cx / mov cl,al is a good way to zero-extend. And use a better assembler (such as NASM) that will give clear error messages about instructions that aren't encodeable. Or use mov cl, al and use dec cl / jnz as the loop condition. – Peter Cordes Commented 2 hours ago @PeterCordes 386+ instructions like movzx do not assemble using MS-DOS / MSDebug. (They do with lDebug.) To @utobi: Where did you obtain the debugger you use? I don't think DOSBox-X ships with any version of Debug. – ecm Commented 2 hours ago Delete @PeterCordes, I'm going with debug because the textbook suggests it. – utobi Commented 2 hours ago @ecm, yes dosbox-x ships with debug: dosbox-x.com – utobi Commented 2 hours ago 2 DOS debug.exe is very inconvenient, it doesn't even support labels for branch targets; you have to do the math yourself for instruction lengths to get target addresses. And as you've already seen, it silently mis-assembles some wrong code. Use it as a debugger if you want (there are other debuggers) for code you assembled separately, but if you want a more user-friendly experience for writing code, use NASM. NASM is also usable for 32 and 64-bit programs under modern OSes, which I'd actually recommend learning first before obscure and obsolete DOS stuff with memory segmentation. – Peter Cordes Commented 2 hours ago @utobi I can't find Debug anywhere in this list or in their repo. Are you sure you installed DOSBox-X from their website and did not install anything else? – ecm Commented 2 hours ago Delete 1 Thank you all for your generous comments and suggestions. I see the issue now and fixed using mov cl,al. dosbox-x can also use 386 instructions. I'll gladly accept if any of you bother to write an answer. – utobi Commented 2 hours ago @ecm I'm pretty sure it's there ;-), at least in my intel-based Mac version. – utobi Commented 2 hours ago 1 I looked some more and found it listed as a supported command. But I didn't find the file itself or where it comes from and what version it is, yet. – ecm Commented 2 hours ago Delete 1 There it is, in a hexdump of a binary file: github.com/joncampbell123/dosbox-x/blob/… – ecm Commented 2 hours ago Delete @utobi: The actual code question is a duplicate of MOV 8 bit to 16 bit register (al to bx) (which shows an error message from another assembler, although I wouldn't recommend emu8086 either; it has its own bugs and quirks). The only thing unique about this question is DOS debug.exe mis-assembling it; IDK if that's a useful thing to have a question about. – Peter Cordes Commented 2 hours ago Using just mov cl,al isn't a good idea; you're relying on the program-startup value of CH to be zero. The loop instruction uses CX not CL. That's why I recommended xor cx,cx first if you want to keep using the loop instruction. – Peter Cordes Commented 1 hour ago 1 Anyway, there's potentially an interesting question about why debug.exe is such a bad assembler, and what to be aware of when using it / what actually happens when you feed it this invalid instruction. Like if you'd used it as a debugger to single-step your code you could have seen the value that ended up in CX, and asked it to disassemble the machine code and seen that it changed your instruction. So for example, "why does debug.exe change MOV CX, AL to MOV CX, AX?" would be a valid and probably unique question you could ask (assuming Jester's right about it assembling that way). – Peter Cordes Commented 1 hour ago 1 The debug.exe that ships with DOSBox-X is "DEBUG version 1.25", a FreeDOS Debug descendant (as is lDebug). I extracted it in pushbx.org/ecm/test/20241108 It accepts the wrong mov cx, al inst. In lDebug this is fixed, it rejects that inst. lDebug is based on FreeDOS Debug v1.13. DOSBox-X should carry the copyright attribution of Debug, but it doesn't. "FreeDOS utilities as binary blobs (FreeDOS; no license) src/builtin/*.cpp" github.com/joncampbell123/dosbox-x/blob/… – ecm Commented 1 hour ago Delete Hmm, in hg.pushbx.org/ecm/fddebug/file/version-1.25/README.TXT#l178 it says "This program is copyrighted, but feel free to distribute and use it as you wish. For full copyright conditions, see the file debug.asm." So I guess it's fine, although some others of the FreeDOS applications probably should be attributed better. The DEBUG.COM from the v1.25 release exactly matches the debug.exe from DOSBox-X. (It's actually a flat format executable so the .exe filename extension is misleading.) – ecm Commented 1 hour ago Delete @PeterCordes I found the bugfix changeset. This change on 2019-10-11 makes the debugger reject mov cx, al: hg.pushbx.org/ecm/ldebug/rev/3bea7a5380de#l1.7 That wasn't intended from what it seems but it is what it is. If I set a breakpoint in this revision's lDDebug on ao15 (0A69) and r byte [ss:3DDD] = al twice then the instruction is incorrectly accepted, same as for the prior changeset. Up to the latest commit (2024-06-01) FreeDOS Debug still sets the opsize variable in ao15 and still accepts mov cx, al – ecm Commented 1 min ago Edit Delete

Baron-von-Riedesel / DOS-debug

Instruction mov cx, al accepted incorrectly #19