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

Reply via email to