Hi Tom,
> On Apr 21, 2023, at 2:01 PM, tom ehlert <t...@drivesnapshot.de> wrote:
>
> Hi ecm,
>
>
>> [1]:
>> https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267
>
> this got me looking into this 'too slow' detection method.
> and it is indeed slow. as in molasse. let me explain.
>
>
> a) isn't
>
> %%Comparing:
> inc di
> lodsb
> cmp al, [es:di]
> jne %%Next
> loop %%Comparing
>
> more or less the definition of
>
> repe cmpsw
>
> ??
Yes, more or less it was a “repe cmpsb”
That was a while ago and I forget the reasoning I did it that way. Possibly,
not requiring a case-specific match.
> b) decompiling the actual code, it's basically
>
>
> for (seg = 10; seg < 0xa000; seg++)
> {
> if (fmemcmp(MK_FP(seg, 9), "LOGGER", DriverLength))
> {
> return found_our_driver_at(seg);
> }
> }
> return failure;
>
> that's indeed slow as it compares all memory up to 0xa000 to lookup the
> driver,
> or up to the drivers address (which is much better most of the time.
Yup it is a very slow way to locate the driver. It was only meant to be
temporary until better method was implemented.
The better method will most likely be INT 0x2D (AMIS).
During the development stage, locating the driver needed to be done quickly so
other things could be developed and tested.
That process went something like this:
1) We could walk the MCB chain…. That will require some overhead and
complexity. Too big of a pain for now (see below).
2) We could walk the device driver chain. Thats fairly straight forward and
easy enough to implement. Lets do that… Hmmm, not all device drivers are
showing up in the chain and logger is not being seen. Let’s not worry about
that for now and do something else.
3) We could hook an interrupt somewhere. Yeah, that will be good and reliable.
Lets do that. But, which one will not cause any conflicts or collisions. Hmmm,
lets worry about it later and just get something that works for now.
4) Well a brute force search will work. It is slower than a glacier and as
clever as a stone. But, it will work well enough that I can get to work on
writing and testing the important stuff.
5) Brute force search it is then with a very few optimizations… For now, good
enough.
Even though the delay incurred when launching the interface program is not very
noticable, it is way to slow.
Now that the important stuff has been written and is being tested, the brute
force search needs to go.
> when I mentioned microseconds, I had the DOS memory chain in mind where you
> would have
> to compare 20-50 locations to your drivers name.
I did consider walking the MCB chain to find it. But, that comes with its own
set of problems. Some blocks contain sub-blocks. The upper memory blocks may or
may not be linked into the primary MCB chain.
There are other aspects involving interaction between the Driver, Interface and
Log that are also just “good enough for now” and will probably be changed a
great deal.
It is an alpha version for a reason.
:-)
Jerome
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
