Quantcast

bsum - compute BSD checksums of your files

classic Classic list List threaded Threaded
139 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Mateusz Viste-5
On Mon, 10 Apr 2017 23:30:35 -0500, Rugxulo wrote:
> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
> 127 (signed) byte range. Hence the billions of workarounds (TASM
> "jumps", MASM "option ljmp", etc).

I won't argue about what opcode is or is not available on 8086, since I
did not bother decoding their exact meaning. I do see however that (NASM
at least) can assemble JZ and JZ SHORT in two very different forms, JZ
SHORT being significantly shorter.

  5 00000000 B80100          mov ax, 1
  6 00000003 48              dec ax
  7 00000004 746A            jz short gameover

  5 00000000 B80100          mov ax, 1
  6 00000003 48              dec ax
  7 00000004 7503E9DD01      jz gameover

Of course NASM always uses the short form whenever it's possible, but
when the jump is too far away it silently uses the longer form, hence the
need to always specify SHORT if one wants to be sure what's going on.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Rugxulo
Hi,

On Tue, Apr 11, 2017 at 1:26 AM, Mateusz Viste <[hidden email]> wrote:

> On Mon, 10 Apr 2017 23:30:35 -0500, Rugxulo wrote:
>>
>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>> "jumps", MASM "option ljmp", etc).
>
> I won't argue about what opcode is or is not available on 8086, since I
> did not bother decoding their exact meaning. I do see however that (NASM
> at least) can assemble JZ and JZ SHORT in two very different forms, JZ
> SHORT being significantly shorter.
>
>   5 00000000 B80100          mov ax, 1
>   6 00000003 48              dec ax
>   7 00000004 746A            jz short gameover
>
>   5 00000000 B80100          mov ax, 1
>   6 00000003 48              dec ax
>   7 00000004 7503E9DD01      jz gameover
>
> Of course NASM always uses the short form whenever it's possible, but
> when the jump is too far away it silently uses the longer form, hence the
> need to always specify SHORT if one wants to be sure what's going on.

AFAIK, the longer one is 386+ only, hence not available with "cpu
8086". Thus, if it still quietly assembles, that is a bug (but I
thought that was long-ago fixed/avoided).

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

On Mon, 10 Apr 2017 17:57:59 -0400, dmccunney wrote:
> I have to ask.  How many folks *have* platforms now it *wouldn't* run
> on? I suspect the number is *very* small.

Surely, yes. Still, a 700% memory increase for a 10% performance boost
just doesn't feel right. I wrote bsum to cover an extreme case - in such
context I prefer keeping the memory footprint as small as possible.

> Most folks now are trying to get FreeDOS to boot native on a machine
> rather larger and more powerful than the machines DOS was used on, or
> running it in a VM

I'd say that for these machines bsum is irrelevant - they are much better
off using md5 or anything else.

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Mateusz Viste-5
In reply to this post by Rugxulo
On Tue, 11 Apr 2017 02:03:54 -0500, Rugxulo wrote:
> AFAIK, the longer one is 386+ only, hence not available with "cpu 8086".

The above code assembles with "cpu 8086" (NASM 2.12.02).

> Thus, if it still quietly assembles, that is a bug (but I thought that
> was long-ago fixed/avoided).

Perhaps a bug, didn't investigate. My point is - explicitly mentioning
SHORT is always a good idea. Better safe than sorry.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

On Tue, 11 Apr 2017 02:52:06 +0000, Mateusz Viste wrote:
> On Mon, 10 Apr 2017 17:07:30 -0500, Rugxulo wrote:
>> 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.

Checked: your nibble-to-hex version is indeed smaller. Hence it's better
than mine both in terms of space (by 3 bytes) and speed (no jump). Nice!

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

I have to clarify here that my intention was never to compete in any way
with the other algorithms out there. The BSD checksum is a well-known,
and pretty weak (16 bits) checksum. The goal behind bsum was only to
obtain a checksum tool that would run on my 8086 fast enough for me to
not get frustrated, and just good enough to be reasonably sure that the
files I just copied from a diskette and then over network-through-
parallel-port didn't get corrupted in the process.

Mateusz



On Mon, 10 Apr 2017 09:48:41 -0700, Ralf Quint wrote:

> On 4/10/2017 6:36 AM, Mateusz Viste wrote:
>> On Mon, 10 Apr 2017 00:56:17 -0500, Rugxulo wrote:
>>> It would be interesting to see some benchmark numbers for that (for
>>> various specific tools, 8086, 386, etc).
>> Just for the fun of it, I did some quick measures on my 386SX PC,
>> computing various checksums of a 2 MiB file. Results below.
>>
>> BSUM (by Mateusz Viste) :  6.0s (100%)
>> CRC32 (by Joe Forster)  :  8.5s  (70%)
>> CRC32 (by Colin Plumb)  : 26.7s  (22%)
>> MD5 (by Colin Plumb)    : 52.9s  (11%)
>> SHA1 (by Colin Plumb)   : 85.7s   (7%)
>>
>> BSUM is the fastest, which is no surprise since the algorithm is
>> extremely simple (4 CPU instructions). The CRC32 computation by Joe
>> Forster is surprisingly fast as well. It's 30% slower than bsum and the
>> binary is 4x times larger (and I suppose the memory usage is also much
>> higher) but that's still quite impressive for a 32-bit checksum.
> Well, most of all, it's kind of comparing apples and oranges. Those
> benchmark tests mean nothing if you don't compare them with the number
> of possible collisions you get for each of them.
> Though that doesn't mean that there aren't use cases where "simple does
> it"...
>>> Splurge on the memory, give it 32 kb or so. It'll "probably" be faster
>>> with a bigger buffer.
> Nope, won't do a thing. Didn't do much good "back in the days" to use
> anything over 16KB and it is even less relevant on modern hard drives
> with MBs of cache. Or SSDs...
>
> Ralf


------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DOS ideas with fast simple algorithms - was: BSUM BSD checksum

Mateusz Viste-5
In reply to this post by Eric Auer-3
On Mon, 10 Apr 2017 23:21:26 +0200, Eric Auer wrote:
> For checking if downloads worked without noise, I would already want
> something "stronger" than BSUM, such as
>
> https://en.wikipedia.org/wiki/Fletcher%27s_checksum

As already stated in this thread a few times, the BSD checksum is far
from perfect - its major advantage is that it's extremely simple, hence
fast to compute even on a 8088, yet at the time it is reasonable to
assume in normal conditions (ie. no malicious intent) that a file that
shows the same BSD checksum before and after a transfer is indeed the
same file.

Still, since you mention "stronger" algorithms, it might be interesting
(if not entertaining) to see how the BSD checksum compares in terms of
collisions to other algorithms like CRC16, CRC32, Fletcher, etc. I did
try to google that out, but unfortunately the BSD checksum is rarely
mentioned in this kind of research. Would you mind sharing some links
that explain how much stronger the other algorithms are, and what are the
actual chances of hitting a collision by accident with BSUM?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

tom ehlert
In reply to this post by Rugxulo
>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>> "jumps", MASM "option ljmp", etc).
right.

>> I won't argue about what opcode is or is not available on 8086, since I
>> did not bother decoding their exact meaning.

meaning 'I am a lazy, clueless guy, but write anyway ...'

>> I do see however that (NASM
>> at least) can assemble JZ and JZ SHORT in two very different forms, JZ
>> SHORT being significantly shorter.
>>
>>   5 00000000 B80100          mov ax, 1
>>   6 00000003 48              dec ax
>>   7 00000004 746A            jz short gameover
>>
>>   5 00000000 B80100          mov ax, 1
>>   6 00000003 48              dec ax
>>   7 00000004 7503E9DD01      jz gameover
>>
>> Of course NASM always uses the short form whenever it's possible, but
>> when the jump is too far away it silently uses the longer form, hence the
>> need to always specify SHORT if one wants to be sure what's going on.

> AFAIK,
meaning 'I am completely clueless , but offer my unfounded opinion anyway ...'

> the longer one is 386+ only, hence not available with "cpu
> 8086". Thus, if it still quietly assembles, that is a bug (but I
> thought that was long-ago fixed/avoided).

the longer one is 2 instructions instead, automatically generated by NASM
because the intended jump goes farther then 127 bte


c:\>debug
-e 100
1430:0100  00.75   00.03   00.e9   00.dd   00.01
-u 100
1430:0100 7503          JNZ     0105
1430:0102 E9DD01        JMP     02E2


Tom



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

On Mon, 10 Apr 2017 23:30:35 -0500, Rugxulo wrote:
> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
> 127 (signed) byte range. Hence the billions of workarounds (TASM
> "jumps", MASM "option ljmp", etc).

I won't argue about what opcode is or is not available on 8086, since I
did not bother decoding their exact meaning. I do see however that (NASM
at least) can assemble JZ and JZ SHORT in two very different forms, JZ
SHORT being significantly shorter.

  5 00000000 B80100          mov ax, 1
  6 00000003 48              dec ax
  7 00000004 746A            jz short gameover

  5 00000000 B80100          mov ax, 1
  6 00000003 48              dec ax
  7 00000004 7503E9DD01      jz gameover

Of course NASM always uses the short form whenever it's possible, but
when the jump is too far away it silently uses the longer form, hence the
need to always specify SHORT if one wants to be sure what's going on.

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Mateusz Viste-5
In reply to this post by tom ehlert
Hi Tom,

That's nice of you to provide the explanation. I didn't read it
completely (too lazy), nor understand it fully (too stupid), but the
other clueless guy might find it interesting that he was only half wrong.

At the end of the day, I will keep using "JZ SHORT" anyway, 'cause that
just works for me.

cheers,
Mateusz





On Tue, 11 Apr 2017 12:33:17 +0200, Tom Ehlert wrote:

>>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128
>>>> ..
>>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>>> "jumps", MASM "option ljmp", etc).
> right.
>
>>> I won't argue about what opcode is or is not available on 8086, since
>>> I did not bother decoding their exact meaning.
>
> meaning 'I am a lazy, clueless guy, but write anyway ...'
>
>>> I do see however that (NASM at least) can assemble JZ and JZ SHORT in
>>> two very different forms, JZ SHORT being significantly shorter.
>>>
>>>   5 00000000 B80100          mov ax, 1 6 00000003 48              dec
>>>   ax 7 00000004 746A            jz short gameover
>>>
>>>   5 00000000 B80100          mov ax, 1 6 00000003 48              dec
>>>   ax 7 00000004 7503E9DD01      jz gameover
>>>
>>> Of course NASM always uses the short form whenever it's possible, but
>>> when the jump is too far away it silently uses the longer form, hence
>>> the need to always specify SHORT if one wants to be sure what's going
>>> on.
>
>> AFAIK,
> meaning 'I am completely clueless , but offer my unfounded opinion
> anyway ...'
>
>> the longer one is 386+ only, hence not available with "cpu 8086". Thus,
>> if it still quietly assembles, that is a bug (but I thought that was
>> long-ago fixed/avoided).
>
> the longer one is 2 instructions instead, automatically generated by
> NASM because the intended jump goes farther then 127 bte
>
>
> c:\>debug -e 100 1430:0100  00.75   00.03   00.e9   00.dd   00.01 -u 100
> 1430:0100 7503          JNZ     0105 1430:0102 E9DD01        JMP    
> 02E2
>
>
> Tom


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Jerome Shidel
Less than 256 bytes of code.

Over 2 Megabytes of controversy.

Shame on you Mateusz!

:-)

All joking aside, from what I gather, your bsum is only meant to verify local files were copied correctly from one machine to another. Most forms of checksums should be sufficient for that task.

Sure a collision is possible. More bits in the checksum reduces the possibility. But even with a SHA 256 hash, the chance of accidental collision is so remote as to be zero. It is still theoretically possible.

How sure do you need to be? Well, you could be absolutely sure by coping them over then back. Then doing a byte level comparison between the original and the copy of a copy.  But why? Now as for a man in the middle of your two machines... Even that check could be thwarted by a crafty attacker.

So, I assume that the checking done by you bsum is the exact level of certainty you desire. Sure enough.

Jerome

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

On Tue, 11 Apr 2017 02:03:54 -0500, Rugxulo wrote:
> AFAIK, the longer one is 386+ only, hence not available with "cpu 8086".

The above code assembles with "cpu 8086" (NASM 2.12.02).

> Thus, if it still quietly assembles, that is a bug (but I thought that
> was long-ago fixed/avoided).

Perhaps a bug, didn't investigate. My point is - explicitly mentioning
SHORT is always a good idea. Better safe than sorry.

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Jerome Shidel <[hidden email]>

Less than 256 bytes of code.

Over 2 Megabytes of controversy.

Shame on you Mateusz!

:-)

All joking aside, from what I gather, your bsum is only meant to verify local
files were copied correctly from one machine to another. Most forms of
checksums should be sufficient for that task.

Sure a collision is possible. More bits in the checksum reduces the
possibility. But even with a SHA 256 hash, the chance of accidental collision
is so remote as to be zero. It is still theoretically possible.

How sure do you need to be? Well, you could be absolutely sure by coping them
over then back. Then doing a byte level comparison between the original and the
copy of a copy.  But why? Now as for a man in the middle of your two
machines... Even that check could be thwarted by a crafty attacker.

So, I assume that the checking done by you bsum is the exact level of certainty
you desire. Sure enough.

Jerome

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Mateusz Viste <[hidden email]>

Hi Tom,

That's nice of you to provide the explanation. I didn't read it
completely (too lazy), nor understand it fully (too stupid), but the
other clueless guy might find it interesting that he was only half wrong.

At the end of the day, I will keep using "JZ SHORT" anyway, 'cause that
just works for me.

cheers,
Mateusz





On Tue, 11 Apr 2017 12:33:17 +0200, Tom Ehlert wrote:

>>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128
>>>> ..
>>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>>> "jumps", MASM "option ljmp", etc).
> right.
>
>>> I won't argue about what opcode is or is not available on 8086, since
>>> I did not bother decoding their exact meaning.
>
> meaning 'I am a lazy, clueless guy, but write anyway ...'
>
>>> I do see however that (NASM at least) can assemble JZ and JZ SHORT in
>>> two very different forms, JZ SHORT being significantly shorter.
>>>
>>>   5 00000000 B80100          mov ax, 1 6 00000003 48              dec
>>>   ax 7 00000004 746A            jz short gameover
>>>
>>>   5 00000000 B80100          mov ax, 1 6 00000003 48              dec
>>>   ax 7 00000004 7503E9DD01      jz gameover
>>>
>>> Of course NASM always uses the short form whenever it's possible, but
>>> when the jump is too far away it silently uses the longer form, hence
>>> the need to always specify SHORT if one wants to be sure what's going
>>> on.
>
>> AFAIK,
> meaning 'I am completely clueless , but offer my unfounded opinion
> anyway ...'
>
>> the longer one is 386+ only, hence not available with "cpu 8086". Thus,
>> if it still quietly assembles, that is a bug (but I thought that was
>> long-ago fixed/avoided).
>
> the longer one is 2 instructions instead, automatically generated by
> NASM because the intended jump goes farther then 127 bte
>
>
> c:\>debug -e 100 1430:0100  00.75   00.03   00.e9   00.dd   00.01 -u 100
> 1430:0100 7503          JNZ     0105 1430:0102 E9DD01        JMP
> 02E2
>
>
> Tom


------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Tom Ehlert <[hidden email]>

>>> Unless I'm mistaken, conditional jumps on 8086 don't go beyond -128 ..
>>> 127 (signed) byte range. Hence the billions of workarounds (TASM
>>> "jumps", MASM "option ljmp", etc).
right.

>> I won't argue about what opcode is or is not available on 8086, since I
>> did not bother decoding their exact meaning.

meaning 'I am a lazy, clueless guy, but write anyway ...'

>> I do see however that (NASM
>> at least) can assemble JZ and JZ SHORT in two very different forms, JZ
>> SHORT being significantly shorter.
>>
>>   5 00000000 B80100          mov ax, 1
>>   6 00000003 48              dec ax
>>   7 00000004 746A            jz short gameover
>>
>>   5 00000000 B80100          mov ax, 1
>>   6 00000003 48              dec ax
>>   7 00000004 7503E9DD01      jz gameover
>>
>> Of course NASM always uses the short form whenever it's possible, but
>> when the jump is too far away it silently uses the longer form, hence the
>> need to always specify SHORT if one wants to be sure what's going on.

> AFAIK,
meaning 'I am completely clueless , but offer my unfounded opinion anyway ...'

> the longer one is 386+ only, hence not available with "cpu
> 8086". Thus, if it still quietly assembles, that is a bug (but I
> thought that was long-ago fixed/avoided).

the longer one is 2 instructions instead, automatically generated by NASM
because the intended jump goes farther then 127 bte


c:\>debug
-e 100
1430:0100  00.75   00.03   00.e9   00.dd   00.01
-u 100
1430:0100 7503          JNZ     0105
1430:0102 E9DD01        JMP     02E2


Tom



------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Rugxulo
In reply to this post by Mateusz Viste-5
Hi,

On Tue, Apr 11, 2017 at 7:06 AM, Mateusz Viste <[hidden email]> wrote:
>
> That's nice of you to provide the explanation. I didn't read it
> completely (too lazy), nor understand it fully (too stupid), but the
> other clueless guy might find it interesting that he was only half wrong.

Just to clarify, I'll quote from the A86 text manual:

"
NOTE that for A86, LONG will have effect only on the operand to
an unconditional JMP instruction; not to conditional jumps.  That
is because conditional jumps farther than 127 bytes are available
only on the 386 and later processors.  If you run into this
problem, then chances are your code is getting out of
control--time to rearrange, or to break off some of the
intervening code into separate procedures.  If you insist upon
leaving the code intact, you can replace the conditional jump
with an 'IF cond JMP'.
"

> At the end of the day, I will keep using "JZ SHORT" anyway, 'cause that
> just works for me.

My problem with always explicitly saying "short" is that it's both
unnecessary and verbose. But I (reluctantly) agree that here it's your
best option for safety. (Though I would still hide it behind a
preprocessor macro or whatever, for brevity.)

What disassembler are you using here? I erroneously thought it was
NDISASM. I also misremembered NDISASM as saying "jz near" (only) for
386+ jumps. I also misremembered such near/long jumps as being five
bytes when they are, in fact, only four.

I halfway remembered that the 386+ jz opcode started with 0Fh (sorry,
Tom) but wasn't sure offhand without checking. But here your
disassembler apparently put two jumps on one line, as if only one,
which is weird. I know it's a common idiom, but I didn't think a
literally disassembler would use that! (I double-checked, latest
NDISASM still decodes as two separate instructions.)

0Fh is actually the opcode to (discontinued, 8086-only) "POP CS". Both
FASM and NASM apparently support that (why?), but A86 apparently
doesn't.

Part of the confusion also lies with NASM. In the old days, you had to
explicitly enable -O3 to enable this 8086 conditional jump workaround,
e.g. 0.98.39 (by looking at old code of mine). NASM 2.09 started
enabling -Ox [sic] by default. However, it appears that even with -O0
nowadays, if you're using "cpu 8086", it will still extend your
conditional jumps in this manner. It didn't use to do that
automatically, nor for -O0.

The simple answer is that code size is rarely as important as
programmer convenience. Sure, if you're trying to squeeze every last
byte, you'll maybe accidentally be bit by this. But most people, by
far, don't care about code size and only care about functionality. I'm
only guessing, but that's my impression as to why NASM would always do
this by default nowadays.

P.S. http://stevemorse.org/8086/ is also an interesting read.

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Rugxulo <[hidden email]>

Hi,

On Tue, Apr 11, 2017 at 7:06 AM, Mateusz Viste <[hidden email]> wrote:
>
> That's nice of you to provide the explanation. I didn't read it
> completely (too lazy), nor understand it fully (too stupid), but the
> other clueless guy might find it interesting that he was only half wrong.

Just to clarify, I'll quote from the A86 text manual:

"
NOTE that for A86, LONG will have effect only on the operand to
an unconditional JMP instruction; not to conditional jumps.  That
is because conditional jumps farther than 127 bytes are available
only on the 386 and later processors.  If you run into this
problem, then chances are your code is getting out of
control--time to rearrange, or to break off some of the
intervening code into separate procedures.  If you insist upon
leaving the code intact, you can replace the conditional jump
with an 'IF cond JMP'.
"

> At the end of the day, I will keep using "JZ SHORT" anyway, 'cause that
> just works for me.

My problem with always explicitly saying "short" is that it's both
unnecessary and verbose. But I (reluctantly) agree that here it's your
best option for safety. (Though I would still hide it behind a
preprocessor macro or whatever, for brevity.)

What disassembler are you using here? I erroneously thought it was
NDISASM. I also misremembered NDISASM as saying "jz near" (only) for
386+ jumps. I also misremembered such near/long jumps as being five
bytes when they are, in fact, only four.

I halfway remembered that the 386+ jz opcode started with 0Fh (sorry,
Tom) but wasn't sure offhand without checking. But here your
disassembler apparently put two jumps on one line, as if only one,
which is weird. I know it's a common idiom, but I didn't think a
literally disassembler would use that! (I double-checked, latest
NDISASM still decodes as two separate instructions.)

0Fh is actually the opcode to (discontinued, 8086-only) "POP CS". Both
FASM and NASM apparently support that (why?), but A86 apparently
doesn't.

Part of the confusion also lies with NASM. In the old days, you had to
explicitly enable -O3 to enable this 8086 conditional jump workaround,
e.g. 0.98.39 (by looking at old code of mine). NASM 2.09 started
enabling -Ox [sic] by default. However, it appears that even with -O0
nowadays, if you're using "cpu 8086", it will still extend your
conditional jumps in this manner. It didn't use to do that
automatically, nor for -O0.

The simple answer is that code size is rarely as important as
programmer convenience. Sure, if you're trying to squeeze every last
byte, you'll maybe accidentally be bit by this. But most people, by
far, don't care about code size and only care about functionality. I'm
only guessing, but that's my impression as to why NASM would always do
this by default nowadays.

P.S. http://stevemorse.org/8086/ is also an interesting read.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Mateusz Viste-5
In reply to this post by Rugxulo
On Tue, 11 Apr 2017 22:24:56 -0500, Rugxulo wrote:
> My problem with always explicitly saying "short" is that it's both
> unnecessary and verbose.

Apparently not so "unnecessary" after all, if one really wants to use a
short jump, and not some other contraption.

> 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, and
I didn't figure out any quick and easy workaround (again, too stupid).

The output I pasted before was copied from the NASM listing (-l). And
although I do look at the listing carefully, I do not bother decoding the
opcodes by hand (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.

> 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?

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bsum - compute BSD checksums of your files

Karen Lewellen-2
In reply to this post by Mateusz Viste-5
From: Rugxulo <[hidden email]>

Hi,

On Wed, Apr 12, 2017 at 2:03 AM, Mateusz Viste <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-user
12345 ... 7
Loading...