🚀 go-pugleaf

In article <6042@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
>In article <5@wb1.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes:
>> Unfortunately, some of
>>these instructions are not implemented by the MicroVAX-II hardware.
>>As it turns out, what is happening is that your tests (including
>>Dhrystone) are causing kernel traps to emulate those instructions!
>
>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).

Concur somewhat at this point.

>There are two ways to do this. ...

There is a third and much more efficient way:

	Shared resident libraries.

This way all you have to do is make sure you install the correct
library on a particular machine.  Everyone except memory and
disk drive vendors benefit from shared libraries.  Assuming a
vectored entry point interface to the library, you can move your
images from one type of Vax to another and your program will
run with the most efficient `str*' routines available for that
machine, ie.  the routines in that machines resident library.
None of this re-link everything that uses `ctime' nonsense either.

Of course some people need resident libraries more than others,
a case in point are the customers of Sun Microsystems.  Here
resident libraries, in addition to a host of other benn'ies
previously alluded to, will put a stop to the following:

	"Gak!!  That was a fifty line program.  It took
	forever to link and it eats up 700k of disk space???"

Since Sun is working on making their system SVID compatible
the wait shouldn't be too long now.  If I remember correctly
Apollo has always had resident libraries, but then I've never
even as much as seen an Apollo product.

			Bjorn R. Bjornsson
			alberta!bjorn