Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Re: Far string/mem functions
Cc: djgpp-workers AT delorie DOT com
Date: Thu, 23 Apr 1998 20:50:57 -0700
Message-ID: <19980424035042.AAG8293@ppp125.cartsys.com>
Precedence: bulk

At 10:50  4/21/1998 +0200, Vik Heyndrickx wrote:
>Nate Eldredge wrote:
>
>I've been writing similar functions, so I'm kinda interested :)
>While writing these functions I ran into several problems, which are
>difficult to solve without getting a NO from d-w. Since there were too
>many NO's I abandoned the idea.
>Below, you find some of my recommandations and hopefully some answers.
> 
>> * Does it seem necessary to document them completely, or can we just list
>> their prototypes and refer users to the corresponding near functions? They
>> are very similar; the only differences are that each pointer arg to the
>> original is replaced by two unsigned args (selector and offset) in the far
>> versions. Functions that returned pointers return the offset only.
>
>There are two different kind of such pointer returns:
>1. The ones that are actually useful such as a matching position for
>e.g. memchr.
>2. The ones that return one of there arguments, like memcpy.
>
>In the first case returning the offset seems fine at first, however what
>do you return to the user in case the original function returns NULL? 0
>won't do the job.

That is a good point which I hadn't thought of. In the normal DS segment,
address 0 is invalid and nothing can go there, but in a segment the user has
created themself that is not necessarily true. Hmm.

Well, if nothing else, it can just be documented. That will turn it into a
Feature :-\

As another possibility, we could abandon everything but `_farmemset', the
function I originally suggested. :) Not that I really recommend it.

>In the latter case returning anything is quite useless because
>simulating the original behaviour exactly is impossible and therefore I
>would return nothing at all.

Yes, it's useless, but by the same token the user trying to use them is
equally useless. Cosmetic, IMHO. I could go either way on this. Anyone else
have comments?

>I plea strongly for type-correctness:
>  selectors are 'short unsigned int'

See below.

>  offsets are 'long unsigned int' (the same type as size_t)

I just followed `movedata's example. I don't see a problem offhand with
using `unsigned long' instead, though it seems a moot point since they're
really the same thing. Maybe DJ or whoever wrote `movedata' can tell why
they chose `unsigned'?

>The gain from using unsigned for the selector instead is so marginal and
>the potential number problems that may arise relatively so large that
>'short unsigned' is the best choice.

It makes assembly functions that take selector arguments much easier to
write when all arguments are 4 bytes in size, and there is (as you mention)
a small performance difference.

However, I can't think of any of the "potential number of problems" that
would arise. Can you list some?

>> * As written currently, my `_farmemcmp' may (for efficiency) touch memory
>> beyond the first byte mismatch, though not beyond the given limit. Is that
>> legal?
>
>Even touching memory beyond the given limit (were speaking here about 3
>bytes at most, right?) would be acceptable, I think.

Yes, it is 3 bytes at most, but it is theoretically possible that those
bytes beyond the limit are illegal to touch. For instance, if the user has a
segment where the limit is byte-granular, they might go to the very end.
(Page-granular won't be hurt due to alignment reasons). It's not really a
problem; I just found it made the `_farstrchr' and such harder to write.

>> Current status:
>> * I have written all the functions I plan to, though I have NOT yet tested
>> them at all.
>
>I volunteer...

I would like to get them at least grossly working first. It will be a lot
easier for me that way. But I appreciate the offer, and will welcome the
help once I get to that stage. (It should be sometime next week; I'm rather
busy until then.)

>> * Many of the functions are very inefficient (`_farstrcasecmp', for
>> instance, does a segment register load for each character). Yes, I'm lazy.
>
>That's really BAD ;-)
>
>> * I have not written a makefile nor any documentation.
>
>I don't volunteer :-)
>
>> I will post them here (or would it be better to upload to delorie.com? It's
>> about 16K altogether right now) when they are more stable, and when I can
>> integrate them into the libc.
>
>If you could send me a copy... or an URL...

I will, when I get there. Perhaps I will upload it to my web site, if I can
figure out how (I'm a bit new to this http thing :)

>BTW, recently, I sent DJ a new asm version of memmove which can easily
>be tweaked to do also far memmove's. That routine also supports a
>generally faster non-inlined memcpy. I hope DJ will put it in the next
>alpha release.

That's good, actually, because I just remembered I didn't write a `memmove'.
:) My `memcpy' is just a wrapper around `movedata'; I figured, why reinvent
the wheel?

Thanks,

Nate Eldredge
nate AT cartsys DOT com