strcpy

[der Mouse]

In article <848 at cresswell.quintus.UUCP>, ok at quintus.UUCP (Richard A. O'Keefe) writes:
> In article <10895 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
>> In article <4295 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>>> And so far nobody has named a compiler/library/OS/environment that
>>> *doesn't* just copy left to right.
>> To be fair, I *do* know of one:  The 4.3BSD Vax strcpy() uses the
>> Vax locc and movc3 instructions.  movc3 moves in whichever direction
>> is nondestructive.

This is not quite true.  I just looked at it, and the 4.3 VAX strcpy()
does use locc and movc3.  However, this doesn't imply that the strcpy()
operation is done whichever way is nondestructive.  Why is this?
Because the string may be longer than 64k.  The code loops, from left
to right, doing 64k-1 chunks until it has it whittled down to less than
64k.  Thus, the code works right for non-overlapping operands and for
cases where left-to-right would work.  The other sort of overlap will
work non-destructively for lengths up to 64k-1, and above that will do
replication with a stride of 64k-1.

> This may not be such a wonderful idea:  according to the DEC manuals,
> some VAX models do not implement the locc instruction.

Primarily the MicroVAX-II (and possibly the -I as well).

> (The machine will trap to some sort of library which emulates the
> missing instructions.)

It just traps through a specific vector in the SCB, much like a device
interrupt or an exception.

> Getting this right for strings longer than 2^16-a few characters must
> be a nightmare:  both locc and movc3 have a 16-bit length operand.

This is whence the looping I mentioned above.

> (This has never made sense to me.)

The 16-bit limitation on the string instructions?  Yeah, me either.
Anybody from DEC care to explain what this silly restriction is doing
there?

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu