Newsgroups: comp.arch
Path: utzoo!utgpu!jarvis.csri.toronto.edu!hub.toronto.edu!thomson
From: thomson@hub.toronto.edu (Brian Thomson)
Subject: Re: String lengths
Message-ID: <8902082129.AA05971@beaches.hub.toronto.edu>
Organization: University of Toronto
References: <8876@alice.uucp> <8442@aw.sei.cmu.edu> <enj91#24gKdg=eric@snark.uu.net> <88850@sun.uucp> <88853@sun.uucp> <37529@oliveb.olivetti.com>
Date: Wed, 8 Feb 89 16:29:29 EST

In article <37529@oliveb.olivetti.com> chase@Ozona.UUCP (David Chase) writes:
>
>You should also check out the string operations on the 360/370 sort of
>machines; BCPL was running there (rather well) a very long time ago.
>I think that those operations worked on at most 256 characters (and, I
>should add, NOT on 0-length strings).  It may well be another case of
>architecture influencing language design (note that a zero-length BCPL
>string actually contains one byte -- the zero count).
>

But the 360 implementation was not the first implementation.  It
is probably more correct to say that the maximum string length was
implementation-dependent, but tended to be 255 because many machines
have 8-bit bytes.

Also, I don't remember the 360 code generator producing any string
instructions, although it certainly could be persuaded to produce
byte (character) instructions.  By that time, the language had been
extended with the packed string selector operator "%", so

     GETBYTE(S, I)         was equivalent to the (inline)   S%I
and  PUTBYTE(S, I, C)      to      S%I := C

-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

