From: Rugxulo <rugx...@gmail.com> Hi,
On Wed, Apr 12, 2017 at 2:03 AM, Mateusz Viste <mate...@nospam.viste.fr> 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): http://www.delorie.com/djgpp/doc/utils/utils_7.html 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 lazy!). > 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, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user --- Internet Rex 2.29 * Origin: capcity2.synchro.net - 502/875-8938 (276:10/901) --- Synchronet 3.15a-Linux ListGate 1.3 * Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
