[comp.arch] *Why* do modern machines mostly hav

robison@uiucdcsb.cs.uiuc.edu (07/26/87)

Actually the Burroughs machines have a 51-bit word, 48 bits + a three bit tag.
The real tragedy is that their ALGOL does not support packed record structures,
so the programmers (including myself) have to specify how to pack information 
into words.  All that ``high-level'' ALGOL is unfortunately very dependent 
upon a 48-bit word-size and thus extremely non-portable.  In my experience
with the Burroughs systems and many C boxes, a well written C program is 
less machine dependent!

- Arch

rick@datacube.UUCP (08/07/87)

/* Written  5:18 pm  Aug  5, 1987 by ram@elmgate.UUCP in datacube:comp.arch */
>They use 18 bit words ( 9 bit bytes).
>.. used a 10 bit byte.  And a nine bit tape.  This was weird


	Not really 9,10 bit words though. You don't get to use these
	bits, the board does, (for parity and/or EDC). The price you
	pay for correct data always is extra memory. This explains
	also 36 bit long words (4 * 8 data bits =32 data bits)+(4*1 parity 
	4 parity bits) =36 bits total.

rick@datacube.UUCP ( please forgive incorrect ettiquete I am new to the net)
/* End of text from datacube:comp.arch */

molly@killer.UUCP (Molly Fredericks) (08/14/87)

In article <101200004@datacube>, rick@datacube.UUCP writes:
> 
> /* Written  5:18 pm  Aug  5, 1987 by ram@elmgate.UUCP in datacube:comp.arch */
> >They use 18 bit words ( 9 bit bytes).
> >.. used a 10 bit byte.  And a nine bit tape.  This was weird
> 
> 
> 	Not really 9,10 bit words though. You don't get to use these
> 	bits, the board does, (for parity and/or EDC). The price you
> 	pay for correct data always is extra memory. This explains
> 	also 36 bit long words (4 * 8 data bits =32 data bits)+(4*1 parity 
> 	4 parity bits) =36 bits total.
> 
> rick@datacube.UUCP ( please forgive incorrect ettiquete I am new to the net)
> /* End of text from datacube:comp.arch */

DEC-System 10's and 20's actually had 36 bits in the word, all of which
where addressable.  The addresses where 18 bits long, which I think
explains the 18 bit Unibus addresses on early PDP-11's

The 10's had 2 or 3 character modes.  The first has 6 bit.  Six characters
were packed into a 36 bit word.  That gave 6 characters per word, no
parity.

The next mode was 7 bit ascii.  5 characters were packed into 36 bits with
the last bit wasted.  This was used as I understand for storing data in
datafiles.  The six bit stuff tended to shift all of your characters into
upper case, so that wasn't so hot for text files and anything else you
didn't want to become monocase.

There may have been an 8 bit ascii mode, but I don't ever recall doing
anything with it.

The memory checking was done someplace else as I once got loaded into a
bad memory box and crashed the system with a parity error.  The DEC-10
we had had PDP-11/23's working as node concentrators and I had the
privilege of getting the error message first ...  (Before everyone else
got `Path to remote system is lost')

Molly
-- 
       Molly Fredericks       UUCP: { any place real }!ihnp4!killer!molly
    Disclaimer:  Neither me, nor my cat, had anything to do with any of this
  "I love giving my cat a bath, except for all those hairs I get on my tongue"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

hwe@beta.UUCP (Skip Egdorf) (08/15/87)

In article <1332@killer.UUCP>, molly@killer.UUCP (Molly Fredericks) writes:
> 
> DEC-System 10's and 20's actually had 36 bits in the word, all of which
> where addressable.  The addresses where 18 bits long, which I think
> explains the 18 bit Unibus addresses on early PDP-11's
> 
> The 10's had 2 or 3 character modes.  The first has 6 bit.  Six characters
> were packed into a 36 bit word.  That gave 6 characters per word, no
> parity.
> 
> The next mode was 7 bit ascii.  5 characters were packed into 36 bits with
> the last bit wasted.  This was used as I understand for storing data in
> datafiles.  The six bit stuff tended to shift all of your characters into
> upper case, so that wasn't so hot for text files and anything else you
> didn't want to become monocase.
> 
> There may have been an 8 bit ascii mode, but I don't ever recall doing
> anything with it.

They also had 1-bit modes, 2-bit modes, ..., 36-bit modes.

The Dec-10s (and 20s, same machine architecture, different OS support)
had two byte handeling instructions: load byte, and deposit byte.
Each used a "byte pointer" as an operand.
This byte pointer had the normal 18-bit word address and a byte length
so that any size byte could be handeled within a word.
6-bit and 7-bit bytes were common, (7-bits * 5 bytes = 35 bits + one left
over) but some things (anyone from Stanford out there??) used 9-bit
bytes at 4 per word.
TOPS-10 did its IO by transfering to a buffer and giving you a byte pointer
to the buffer. This was a 7-bit byte pointer by default, but could be
changed if you wanted to use a file with weird bytes.

This is also the classic C example of a normal (int, float, etc) pointer
at 18-bits being shorter than a 'char *' at 36 bits.

				Skip Egdorf

guy%gorodish@Sun.COM (Guy Harris) (08/16/87)

> This is also the classic C example of a normal (int, float, etc) pointer
> at 18-bits being shorter than a 'char *' at 36 bits.

In other words, an array of 10 "int *"s would require 5 words, not 10, and an
"int **" would require at least 19 bits (since the address of an "int" * would
have to include the address of the word as well as a bit to indicate which
halfword it was in)?  I'd be surprised if this was the case in any DEC-10 or
DEC-20 C implementation.  This *is*, however, a case where an "int *" would
have a different format from a "char *", although if you ignore the extra
byte-pointer stuff you could use a "char *" as an "int *".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

daveb@geac.UUCP (Brown) (08/17/87)

In article <25740@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>> This is also the classic C example of a normal (int, float, etc) pointer
>> at 18-bits being shorter than a 'char *' at 36 bits.
>In other words, an array of 10 "int *"s would require 5 words, not 10, and an
>"int **" would require at least 19 bits...
> ...  I'd be surprised if this was the case in any DEC-10 or
>DEC-20 C implementation. 

I'm not sure about the DEC-10, but the Honeywell 36-bit machines used
the high half (the CAR) of the word as a pointer-to-word, and any
bit/byte addressing info was in the high end of the lower half.  The
C (and late-model B!) compilers therefore had an addressing scheme
that was guaranteed to fit in whole-words, even if the pointers were
to bits... :-).
-- 
 David Collier-Brown.                 |  Computer Science
 Geac Computers International Inc.,   |  loses its memory
 350 Steelcase Road,Markham, Ontario, |  (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.