derived types

[Robert Viduya]

><
> weird machines such as u1108 (b=9, w=18, l=36, q=72) and cdc6400 (b=6?,
> w=15, l=30, q=60) would have to adapt as best they can (they kinda have
> to now anyway).
>

Actually, the CDC 6400 series, as well their 170 series, has 18 bit addresses,
which mean pointers have to be at least that much.  Also, addressing is done
only on 60-bit words.  All arithmetic operations are done with 60-bits per
operand, minimum (except for addressing arithmetic).  The native character
set is a 6-bit one, which means 10 characters per word.  Accessing one character
means loading a word and doing shifts and ands.  In adapting C to that
architecture, it would be more time efficient to store one character per word,
however, storage would be drastically wasted (when you've only got an 18-bit
address space, storage can be at a premium (the architecture doesn't support
virtual memory)).  NOS, one of the operating systems available for the 170
series, supports an 8-in-12 bit character set where each character is
represented as the lower 8-bits in a 12-bit cell (in true ASCII).

If I were to adapt C to the 170 series, I would set the following types:

	int			60-bits
	long int		60-bits
	short int		30-bits (2 per word)
	pointer			30-bits (2 per word, upper 12 bits used for
					 indexing into words)
	char			12-bits (5 per word, strings aligned on
					 word boundarys)
	float			60-bits
	double			60-bits

Obviously, there'll be a lot of wasted time when scanning a string, but
proper register management can minimize that (there are enough registers
to hold everything).  Short ints should be used only to save storage and
nothing else.

				robert
-- 
Robert Viduya
    Office of Computing Services
    Georgia Institute of Technology, Atlanta GA 30332
    Phone:  (404) 894-4669

...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert