Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <3705@goanna.cs.rmit.oz.au>
Date: 7 Sep 90 03:14:41 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <5063@daffy.cs.wisc.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 35

In article <5063@daffy.cs.wisc.edu>, bmiller@rt2.cs.wisc.edu (Brian Miller) writes:
>     Just off hand, would any of you familiar with past
> Burroughs machines care to provide some info on how they
> dealt with bit-oriented data?

B6700:
	48 bit data + 3 bit tag + parity&c

Pointers said "element I of such-and-such an array" (somewhat indirectly,
but you could figure out which pointers pointed into what array) and gave
the element size:  4 bit unit (think packed decimal), 6 bit unit (think
BCD/BCL 6-bit chars, later dropped), 8 bit unit (think EBCDIC char),
48 bit unit (think "int"), 96 bit unit (think "double").

No bit pointers.

There were bit *tables*, so-called TRUTHTABLEs, used to represent
sets of characters (IBM fans, think "TRT").  They were 32 bits per
word, if I remember correctly.

Bit *fields* were supported directly:
	field := word.[offset_from_lsb:size_in_bits];
	... word & field[source_offset:destination_offset:size_in_bits] ...
-- I probably have the argument order wrong here --
This was on the B5500 as well, but for some reason that numbered the bits
the other way.  The bit field instructions weren't all that different
from that the M68020 and M88k provide.

So to set bit I of A[J] (where 0 <= I < 48), you'd do
	A[J].[I:1] := 1;

(The DEC-10, now, that _did_ have bit pointers...)

-- 
You can lie with statistics ... but not to a statistician.