Mail Archives: djgpp-workers/1997/10/24/06:49:29
On Thu, 23 Oct 1997, Vik Heyndrickx wrote:
> 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.
`memcpy' is ANSI, we cannot change the order here.
`movedata' order of arguments is compatible with the function by the
same name from Borland libraries. Only `dosmemXX' is DJ's invention.
> But, it seems hard to memorize by a newbie and also a 'not
> so'-newbie.
Newbies shouldn't mess with them. Non-newbies get their title by
passing the test whereby they are required to remember the argument
order by heart, so they by definition remember it ;-).
> I propose to use the memcpy order.
I think it will break a lot of code (or require a libc rewrite). You
could of course add new functions with different names, but I think
this will only add to confusion (too many functions that do the same).
> 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.
They only have to cast if they want to compile with -Wall and don't
like the warnings. Otherwise, if they include the header it should
compile without a cast. Doesn't it?
> 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.
`movedata' can be used to move between two segments neither of which
is your DS. For example, imagine moving data between two
memory-mapped devices.
> And that's a
> pretty important optimization considering the execution time of "movl
> %0,%ds" in protected mode.
`movedata' should be used for large buffers, where the overhead of the
DS reload is negligible. If they need to move small buffers, they
should use `_farnspokeXX' which done't reload DS/ES.
> 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
Is this good enough a reason to justify the code bloat? After all,
creating such a selector is only a bunch of code lines, and even the
FAQ shows how to do that. And most people who are lazy use nearptrs
anyway.
- Raw text -