From: Mateusz Viste <mate...@nospam.viste.fr>
On Mon, 10 Apr 2017 17:07:30 -0500, Rugxulo wrote:
> Blair's (16-bit, FD) MD5SUM can do all of those hashes as well. Not sure
> if it'd be faster, though.
I believe that's the one I used. If I understand correctly, the original
author is Colin Plumb, and Blair took the maintenance of it at some point.
> Believe me, shrinking size is fairly easy,
If you say so.
> but it's a tradeoff in accidental errors, readability,
> and speed.
Unless it's a goal in itself ("keep the whole thing in 256 bytes"), as is
the case of bsum.
> Irrelevant aesthetics: lines too long (shouldn't be more than 80),
I'll skip all aesthetics remarks, since these are a rather personal thing.
> irrelevant "jz short ..." (when "short" conditional jump is always
> mandatory for "cpu 8086").
I don't think so.
Note that short means "8 bit jump" in this context, and NOT "16 bit jump".
> "section .data align=1" is probably what you intended here. (No need to
> comment it out entirely.
No need to have it either (not in tiny model).
> The program does not end in a CR+LF pair. Thus the output is an
> incomplete line. Not a huge deal but still (sometimes) noticeable.
True. I noticed that command.com adds a CR+LF pair whenever a program
doesn't end with those. This seems to be consistent with both FreeDOS and
MS-DOS, so I thought I'd exploit this to save a few bytes in the program.
> "int 21h // xchg ax, bp // int 21h" is repeated several times. If you
> really want to save space, put "msgquit:" before the first one and "jmp
> short msgquit" for the others (since this is quitting the program
> anyways).
Indeed, that would save 1 byte or 2. Good catch.
> BTW, most asm devs actively hate "loop" in lieu of "dec // jnz". Not
> sure if this would really be worth it, even for your 8086.
Actually my trunk version (svn) does avoid loop in favor of dec/jnz.
The former is shorter by one byte, but 3 times slower than the latter
(5/6 clks vs 2 clks).
> "shl bx, cl" (where CL=4) is also shunned, AFAIK, on 8086 machines, in
> lieu of speedier (times 4) "shl bx,1".
But repeated shl bx,1 is so much bigger. I definitely prefer shl bx,cl,
at least whenever not in performance-critical parts.
> Converting hex nibble to ASCII shouldn't need a jump at all. On the 8086
> all jumps are very slow. Best to avoid them entirely if possible.
> Here you can easily use the old "cmp al, 0Ah // sbb al, 69h // das"
> trick instead. But since you're only printing hex one time (instead of
> thousands), you probably don't care.
Indeed, I care little about jumps there, but still your version might be
shorter, which would make it interesting. Will compare.
Mateusz
------------------------------------------------------------------------------
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
