From: Mateusz Viste
On Wed, 12 Apr 2017 04:39:35 -0500, Rugxulo wrote:
> It worked fine (redirecting) for me yesterday! I can't imagine why it
> wouldn't work for you.
>
> Oh, before I forget, are you perhaps invoking NDISASM via some .BAT?
> Of course a .BAT doesn't really redirect (under FreeCO
From: Mateusz Viste
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 fixe
From: 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 t
From: Rugxulo
Hi,
On Wed, Apr 12, 2017 at 2:03 AM, Mateusz Viste 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
From: "Bret Johnson"
> I double-checked, latest NDISASM still decodes as two separate instructions.
A disassembler would not report two separate instructions unless the actual
compiled code had two separate instructions. Every assembler/compiler I know
of does little "tricks" to make the progra
From: Tom Ehlert
>>> 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 bot
From: Mateusz Viste
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,
From: dmccunney
On Mon, Apr 10, 2017 at 9:36 AM, Mateusz Viste wrote:
> On Mon, 10 Apr 2017 00:56:17 -0500, Rugxulo wrote:
>
>> Splurge on the memory, give it 32 kb or so. It'll "probably" be faster
>> with a bigger buffer.
>
> At the cost of reducing the number of platforms it would be able to
From: Rugxulo
Hi,
On Tue, Apr 11, 2017 at 7:06 AM, Mateusz Viste 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
From: Mateusz Viste
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 bsu
From: Mateusz Viste
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 mainte
From: Rugxulo
Hi again,
On Mon, Apr 10, 2017 at 8: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 m
From: Rugxulo
Hi,
On Mon, Apr 10, 2017 at 9:52 PM, Mateusz Viste wrote:
> On Mon, 10 Apr 2017 17:07:30 -0500, Rugxulo wrote:
>
>> 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 c
From: Mateusz Viste
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 ava
From: Mateusz Viste
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
From: Mateusz Viste
On Tue, 11 Apr 2017 02:52:06 +, 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
From: Mateusz Viste
Hello,
I needed to verify the integrity of a few files after transferring them
to/from my 8086 PC the other day. The obvious method for such task is
computing a checksum of the file, like MD5, SHA1, etc... However, on an
8086 this may take ages (even on a fairly fast 386, com
From: Dale E Sterner
Would you or anyone else know if there is an 802.11 client for dos?
Never heard of one but you guys know alot more than I ever will.
cheers
DS
On Mon, 10 Apr 2017 13:36:24 + (UTC) Mateusz Viste
writes:
> On Mon, 10 Apr 2017 00:56:17 -0500, Rugxulo wrote:
> > It woul
From: Mateusz Viste
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. R
From: Ralf Quint
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,
>
From: Rugxulo
Hi,
I haven't tried this (yet), but nice work!
On Sun, Apr 9, 2017 at 1:16 PM, Mateusz Viste wrote:
>
> I needed to verify the integrity of a few files after transferring them
> to/from my 8086 PC the other day. The obvious method for such task is
> computing a checksum of the fi
On Wed, 12 Apr 2017 04:39:35 -0500, Rugxulo wrote:
> It worked fine (redirecting) for me yesterday! I can't imagine why it
> wouldn't work for you.
>
> Oh, before I forget, are you perhaps invoking NDISASM via some .BAT?
> Of course a .BAT doesn't really redirect (under FreeCOM) without kludge,
>
> I double-checked, latest NDISASM still decodes as two separate instructions.
A disassembler would not report two separate instructions unless the actual
compiled code had two separate instructions. Every assembler/compiler I know
of does little "tricks" to make the programmer's job a little e
Hi,
On Wed, Apr 12, 2017 at 2:03 AM, Mateusz Viste 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
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
Hi,
On Tue, Apr 11, 2017 at 7:06 AM, Mateusz Viste 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 q
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 c
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 wo
>>> 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
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
Hi,
On Tue, Apr 11, 2017 at 1:26 AM, Mateusz Viste 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).
>
>
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
Hi,
On Mon, Apr 10, 2017 at 9:52 PM, Mateusz Viste wrote:
> On Mon, 10 Apr 2017 17:07:30 -0500, Rugxulo wrote:
>
>> 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
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 fru
On Tue, 11 Apr 2017 02:52:06 +, 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,
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 p
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
Hi again,
On Mon, Apr 10, 2017 at 8: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 38
On Mon, Apr 10, 2017 at 9:36 AM, Mateusz Viste wrote:
> On Mon, 10 Apr 2017 00:56:17 -0500, Rugxulo wrote:
>
>> Splurge on the memory, give it 32 kb or so. It'll "probably" be faster
>> with a bigger buffer.
>
> At the cost of reducing the number of platforms it would be able to run
> on.
I have
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
Would you or anyone else know if there is an 802.11 client for dos?
Never heard of one but you guys know alot more than I ever will.
cheers
DS
On Mon, 10 Apr 2017 13:36:24 + (UTC) Mateusz Viste
writes:
> On Mon, 10 Apr 2017 00:56:17 -0500, Rugxulo wrote:
> > It would be interesting to see
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 (
Hi,
I haven't tried this (yet), but nice work!
On Sun, Apr 9, 2017 at 1:16 PM, Mateusz Viste wrote:
>
> I needed to verify the integrity of a few files after transferring them
> to/from my 8086 PC the other day. The obvious method for such task is
> computing a checksum of the file, like MD5, SH
Hello,
I needed to verify the integrity of a few files after transferring them
to/from my 8086 PC the other day. The obvious method for such task is
computing a checksum of the file, like MD5, SHA1, etc... However, on an
8086 this may take ages (even on a fairly fast 386, computing the MD5 sum
44 matches
Mail list logo
