Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!amdahl!chuck
From: chuck@amdahl.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: String Handling and run-time libraries
Message-ID: <6073@amdahl.UUCP>
Date: Tue, 31-Mar-87 21:34:09 EST
Article-I.D.: amdahl.6073
Posted: Tue Mar 31 21:34:09 1987
Date-Received: Fri, 3-Apr-87 06:24:33 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15694@sun.uucp> <5@wb1.cs.cmu.edu> <6042@mimsy.UUCP>
Reply-To: chuck@amdahl.UUCP (Charles Simmons)
Organization: Amdahl Corp, Sunnyvale CA
Lines: 48

In article <6042@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <1531@husc6.UUCP> reiter@harvard.UUCP (Ehud Reiter) writes:
>>[strcpy is inordinately slow on a uVax II running 4.3BSD]
>
>In article <5@wb1.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes:
>>[MicroVAX-II doesn't have the same hardware as a VAX]
>
>Exactly.  Strcpy, strcat, and strlen were all modified to use the
>Vax `locc' instruction to find the ends of strings.  This instruction
>is not implemented in hardware in the uVax II.  The obvious solution
>is to arrange the libraries so that on a uVax, programs use a
>straightforward test-byte-and-branch loop (see sample code below).
>
>There are two ways to do this.  One could attempt to determine at
>run-time whether `locc' is available; or one can simply assume that
>anything compiled on a uVax will run on a uVax, and anything compiled
>on a `big Vax' will run on a big Vax.  The former would be hard,
>requring a system call, but would likely be worthwhile if this
>could be done at most once per program run.  The latter is easy:
>just build libc.a differently on a uVax (and then watch rdist run,
>and weep).
>
>Both tricks, however, require some way for user programs to discover
>which CPU is executing them.  A `getcputype' call, anyone?  (But
>what about dynamic process relocation, where a program might move
>from one CPU type to another?  [ECAPISTRANO, process migrated])

Actually, there is a third method.  When using shared subroutine libraries
it can be advantageous to keep all routines in the library bound into
one large file with a jump vector at the top of the file.  When a program
issues a library subroutine call, it branches to a canonical location
in the jump vector for that subroutine, and the jump vector branches to
the appropriate subroutine.

This type of implementation would even work for processes that migrated
from one CPU to a similar, but slightly different, CPU if both CPUs
implemented a shared subroutine library with jump vectors at the same
locations.

For example, on a VAX, a subroutine would call strcpy which would cause
a subroutine call to location 0x01FC in the shared subroutine library.
This location would then branch to code which performed a 'locc' and
'mov3' (or whatever).  When the code migrated to a MicroVAX-II, the code
would still call strcpy by branching to location 0x01FC in the shared
subroutine library.  But this time, this location would branch to
code which performed a simple move-bytes-until-null loop.

-- Chuck