Date: Fri, 24 Oct 1997 12:47:37 +0200 (IST) From: Eli Zaretskii To: Vik Heyndrickx cc: djgpp workers Subject: Re: proposal: movedata, dosmemget, etc. replacement In-Reply-To: <344F2649.5B48@rug.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.