Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!unc!mcguffey
From: mcguffey@unc.cs.unc.edu (Michael McGuffey)
Newsgroups: comp.os.vms
Subject: Re: VAXC RTL "bug"
Message-ID: <566@unc.cs.unc.edu>
Date: Tue, 9-Jun-87 09:27:21 EDT
Article-I.D.: unc.566
Posted: Tue Jun  9 09:27:21 1987
Date-Received: Fri, 12-Jun-87 02:14:11 EDT
References: <8706090257.AA28467@ucbvax.Berkeley.EDU>
Reply-To: mcguffey@unc.UUCP (Michael McGuffey)
Distribution: world
Organization: University of North Carolina, Chapel Hill
Lines: 36

In article <8706090257.AA28467@ucbvax.Berkeley.EDU> BOLTHOUSE%MCOPN1@eg.ti.COM writes:
>
>it doesn't seem like much of a "bug" to me to have the RTL only read()
>64K bytes at a time.  that's a standard VAX number for the size of the
>largest string you can manipulate.  look at the VAX architecture manual
>at the MOVC5 instruction, for example.  you'll notice that the srclen
>and dstlen parts of the instruction are *words*, not longwords.  that's
>about 64K.  you can bet RMS (which is what read() eventually calls...)
>uses movc5/movc3 to get the stuff read from system space into your P0
>space...  
>
>'taint a bug, 'tis a feature.  you wouldn't want RMS to have a tight for
>loop to move data around when it can be done with one instruction...
>

No.  But, it would be nice if:

	a) the RTL read() called the RMS function enough times to transfer
		the correct number of bytes.  It's not too difficult.  That's
		how I got around the "bug".

	b) the description of the read() function in the VAXC reference
		manual contained a statement saying the largest read is 64K.

*FLAMEON*
I may be wrong, but doesn't a VAX running your favorite flavor of unix and
a VAX running VMS use the same machine instruction set... or have the unix
hackers rewritten the VAX architecture manual to include a MOVLARGE instruction
to move arbitrarily large strings.  If unix can do the job in one call to 
read(), VMS should be able to also. 
*FLAMEOFF*

Throughout this whole ordeal, I remain faithful to my VAX and VMS.

mike
mcguffey@dopey.cs.unc.edu