Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <344F2649.5B48@rug.ac.be>
Date: Thu, 23 Oct 1997 12:26:17 +0200
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: djgpp workers <djgpp-workers AT delorie DOT com>
Subject: proposal: movedata, dosmemget, etc. replacement
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi workers.

I've a couple of problems with the implementation of movedata,
dosmemput, dosmemget and the _farp* functions. I would like to see these
changed.

I'll do the implementation and documentation of course. I'd also modify
the libc sources to use these functions.

The first problem is the nut-case inconsistent argument order.
 movedata (srcs, srco, dsts, dsto, l)
 dosmemget (src, l, dst)
 memcpy (dst, src, l)
Practically every possible order is covered.
> Not true.

I assume that was caused by the fact that those functions were not
implemented at the same time and by different people.

But, it seems hard to memorize by a newbie and also a 'not so'-newbie.
I propose to use the memcpy order.

The next is that the only alternative for dosmemget/put for moving data
to different segments than _dos_ds is using movedata. Now, you think,
why is that such a problem? Well, movedata requires a pointer to be
casted to an int by the user. I don't like that. And the user has to
specify _my_ds() as a parameter. I don't like that either. After all %ds
or %es needn't get reloaded after all by the processor. And that's a
pretty important optimization considering the execution time of "movl
%0,%ds" in protected mode.

The segments that are now part of _dos_ds could get their own
descriptor, assigned by the startup code. Using a separate descriptor
for each of them has advantages.
I think about:
- The transfer buffer
- The video segment for the primary screen
- The video segment for the secondary screen
- maybe the BIOS data segment

The segments (apart from _my_ds()) that are accessed frequently by
movedata and the _farp* are:
- _dos_ds

These segment could be available by their selectors.

Currently there is no far version of strlen available. Actually there is
one present, but it's far from optimized. far strlen would be called a
lot (filename - transfer buffer).

So what I propose is the following set of functions as a replacement for
movedata, dosmemget, dosmemput, and the _farp*. 

void _fmemget (void *dst,
               unsigned long ofs, unsigned short sel,
               size_t n);
void _fmemput (unsigned long ofs, unsigned short sel,
               const void *src,
               size_t n);
void _fmemcpy (unsigned long dofs, unsigned short dsel,
               unsigned long sofs, unsigned short ssel,
               size_t n);
void _fmemmove (unsigned long dofs, unsigned short dsel,
                unsigned long sofs, unsigned short ssel,
                size_t n);
size_t _fstrlen (unsigned long ofs, unsigned short sel);

The following would force transfers in byte, double byte and quadbyte
quantities.
_fmemget_b
_fmemget_w
_fmemget_l

_fmemput_b
_fmemput_w
_fmemput_l

unsigned char _fpeek_b (unsigned long ofs, unsigned short sel);
void _fpoke_b (unsigned long ofs, unsigned short sel, unsigned char);
and similar for w, l and for the 'no selector' version of these.

I think this list is complete enough? Or should I insert some other
functions?
Note that the function naming is open for discussion. I welcome your
input.

Note the unusual order of offset and segment. This way is the natural
order of the x86 processor and will not limit the future compatibility.

Replacing the old functions would go in three steps:
1. The next non-alpha release of the library source would contain both
functions. The documentation would show the first functions are now
obsolete and the new functions should be used instead. But with both
versions available.
2. The following version (after some time) would #ifdef the old version
out but for the rest fully available. The documentation will show the
way how to make this functions available, next to the fact of course
that the new functions are available
3. The 2nd following version would move the prototypes out of the header
files they are in now and move to some compatibility header file.

Thanks for reading till here. What do you think about it?

Chau.

-- 
+----------------+
| Vik Heyndrickx |
+----------------+