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.


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

Reply via email to