[comp.arch] String length hardware

davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/13/89)

In article <8882@alice.UUCP> dmr@alice.UUCP writes:

>Originally, I believe, there were no operators for accessing
>individual characters in a compact string, though they were
>added later.

  The GE line had support for true string descriptors as early as the
625 (~1962?). There was a "tally word" mechanism which consisted of a
starting address (word), a starting address (char in word), a count for
string size (12 bits), and a bit for 6 or 9 bit bytes.

  This could be used by instructions with modifiers, as below:
	LDA	STR1,CI		; Character indirect
	STA	STR2,SC		; store, move the starting address
				; forward one byte, and decriment the 
				; size by one.
	LDQ	STR3,SCR	; Move the address back one, etc.

  While the 600 line didn't have bytes addressing, they did have the
tally mechanism, which could emulate a stack in 6 or 9 bit bytes, or any
number of words up to (I believe) 64 (might be 63).

  Perhaps when the 68/xxx series replaced the 645 direct byte addressing
was added, I got away from Multics about the end of the 645 era, when GE
decided to sell the computer operation and put the money into nuclear
development, since computers would never be a mass produced item.

-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

lamaster@ames.arc.nasa.gov (Hugh LaMaster) (02/15/89)

The Cyber 205 provides an address/length form of descriptor in hardware
which works with all vector data types.  Unfortunately, the length field
is only 16 bits long, so the longest string you could have would be of
65535.  This really hurts on floating point arrays, though, because now
some arrays are that big.  (In the late 60's, when the ISA was defined,
512K of Core Memory was a BIG NUMBER.)  The hardware descriptor vehicle
is excellent, in my opinion.  The lesson: pick a big number and then
at least double the number of bits.


-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117       

lamaster@ames.arc.nasa.gov (Hugh LaMaster) (02/15/89)

In article <21822@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>512K of Core Memory was a BIG NUMBER.)  The hardware descriptor vehicle
>
>
>


That is 512 KWords (4MB) of Core Memory.



-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117       

mccalpin@loligo.uucp (John McCalpin) (02/15/89)

In article <21822@ames.arc.nasa.gov> lamaster@ames (Hugh LaMaster) writes:
>The Cyber 205 provides an address/length form of descriptor in hardware
>which works with all vector data types.  Unfortunately, the length field
>is only 16 bits long, so the longest string you could have would be of
>65535.  This really hurts on floating point arrays, though, because now
>some arrays are that big.  (In the late 60's, when the ISA was defined,
>512K of Core Memory was a BIG NUMBER.) 
>  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster

The decision to use a 16-bit length field might be repeated if the
instruction set were redesigned today.  There are a number of tradeoffs
between vector length and paging time on a virtual memory machine which
make longer vector lengths potentially expensive.  At the very least,
very long vector lengths might require the addition of a third (larger)
page size for the virtual memory system to deal with.

Current software automatically segments arithmetic loops into
65535-element chunks, similar to the 64-element strip-mining on the
Cray's. The overhead for this on the 205/ETA-10 is negligible.  I do
not think that the current compiler knows about the vector instruction
for byte-oriented string-searching, but the user can get at it with an
explicit hardware call.
----------------------   John D. McCalpin   ------------------------
Dept of Oceanography & Supercomputer Computations Research Institute
mccalpin@masig1.ocean.fsu.edu		mccalpin@nu.cs.fsu.edu
--------------------------------------------------------------------