From: Rugxulo <>


On Wed, Apr 12, 2017 at 2:03 AM, Mateusz Viste <> wrote:
> On Tue, 11 Apr 2017 22:24:56 -0500, Rugxulo wrote:
>> What disassembler are you using here? I erroneously thought it was NDISASM.
> I don't use ndisasm for a very trivial reason - I am unable to redirect
> its output to a file, so I don't really know how other people use it

It worked fine (redirecting) for me yesterday! I can't imagine why it
wouldn't work for you.

> I didn't figure out any quick and easy workaround (again, too stupid).

Um, excuse me, but he called you "lazy" and "clueless", not "stupid".
I guess we should add "forgetful".   ;-))  j/k

But I'll point to this anyways, "redir", just for a general tip (in
rare case you didn't already know):

Oh, before I forget, are you perhaps invoking NDISASM via some .BAT?
Of course a .BAT doesn't really redirect (under FreeCOM) without
kludge, e.g. "%COMSPEC% /c".

> The output I pasted before was copied from the NASM listing (-l).

Hmmm, then NASM is being a bit too tricky for its own good.

I do (very naively!) wonder whether "warning: 8086 conditional jump
extended" would be appropriate. Actually, having "[386]" (etc) in
NDISASM output would be nice. (The only workarounds for that are BIEW
and QVIEW, IIRC both of which color-code various instructions. Not
sure about various debuggers off the top of my head.)

> And although I do look at the listing carefully, I do not bother decoding the
> opcodes by hand (too lazy!),

Maybe you should use Lazy Assembler (LZASM)?!    :-P      Nah, it
needs a separate linker, even for .COM (bah, too slow, we're too

> I assume that the assembler knows how to
> encode mnemonics into opcodes - that's his job after all, not mine.
> Ultimately, whether the code is assembled into a "long, 5-byte form of
> jump" or "two separate instructions that emulate a jump" is irrelevant to
> me - in both cases it's still 5 bytes, that all I need to know.

I can't even honestly complain, it's indeed a "feature", not a bug!
Not mandatory but certainly nice to have.

>> The simple answer is that code size is rarely as important as programmer
>> convenience.
> Maybe. But why bother doing assembly then, if not for the control over
> what machine code is generated at the end?

I was trying to imagine thinking like them, not speaking for myself. I
personally like size optimizations in assembly (obviously??). E.g.
"add si,2" is three bytes but (times 2) "inc si" is only two! But you
won't see a lot of programs that actively try to save such few bytes.
Nobody cares. (Well, most other people!)

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Freedos-user mailing list

--- Internet Rex 2.29
 * Origin: - 502/875-8938 (276:10/901)
--- Synchronet 3.15a-Linux ListGate 1.3
 *  Capitol City Online - Frankfort, KY - telnet://

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Freedos-user mailing list

Reply via email to