Mail Archives: djgpp/1997/08/19/00:19:16
In article <Pine DOT D-G DOT 3 DOT 91 DOT 970815111534 DOT 19595G-100000 AT dg1>, "Art S. Kagel" <kagel AT bloomberg DOT com> writes:
> On Wed, 13 Aug 1997, Jeff Weeks wrote:
>
>> Chris Croughton wrote:
>> >
>> > Erik Max Francis wrote:
>> >
>> > I have used one compiler (VAX, possibly?) which had short = int = long
>> > and
>> > all 32 bit. Fortunately, char was still 8 bit (but it needn't be - some
>> > machines have 9 bit chars).
>>
>> 9 bit chars!? Weird. So they used a 16-bit word and ignored 7 bits?
>
> Actually most (but not all) 9-bit character machines use EBCDIC rather
> than ASCII and are 36 bit word machines (IBM, DEC10/20, CDC...) where
BZZZT! Sorry, the DECsystem10 and DECSYSTEM20 were most definitely
ASCII-oriented and mostly used 7-bit bytes packed 5 to a 36-bit word. They had
hardware that could work with bytes of any size <= 36 bits, so long as an
individual byte was not split across a word boundary. There were many bizarre
modes for writing to tape, though, and some used 9-bit bytes internally.
IBM's 36-bit machines were the 704, 709, 7044, 7094, etc. and generally used a
6-bit ancestor of EBCDIC, AFAIR.
> the word size was an even multiple of the character size, or even 48
> bit word machines (Honeywell). And it gets weirder than this, or at
> least it used to. The DEC10's KL5 and DEC20's KL10 processors
What's a KL5? Did they really make that many different versions of the PDP-5
before it evolved into the PDP-8? The DECsystem10 used KA10, KI10, KL10, or
KS10 processors; the DECSYSTEM20 ran on KL10 or KS10 processors (and on the
KC10 that never shipped, *sniff*).
> supported variable character size within a 36 bit word. You could
> define a machine byte pointer to point to any byte size from 1 to 36
> bits and it correctly incremented to skip the unused trailing bits in
> each word (for global pointers). Indeed since a byte pointer could be
> local, ie within the current word only, taking up one data word; or
> global, able to address bytes accross multiple words, taking up two
> data words; and either of these types could be extended to address
> multiple 512KB memory spaces which added another word to either
> pointer; these machines are the source of the caviats in compiler
> documentation to not assume that a pointer is the same as an integer
> or even a long or that an integer pointer could be passed as a
> character pointer without an explicit cast!
>
> The KL10 processor also had built in character set support for
> BCD(6bit), 7-bit ASCII, 8-bit ASCII, and EBCDIC and, if memory serves,
> could assign strings from one character set to the other.
The processor didn't care what encoding you used. To translate between
character sets, you'd generally set up a byte pointer of appropriate size and
address for the source, another for the target, and loop over
load/lookup/store. But I do seem to remember an instruction that would do the
whole loop for you, if you set up a block of five contiguous ACs with two
two-word global byte pointers and a byte count. (Instructions using big AC
blocks were definitely introduced in the KL, and may or may not have been in
the more compact KS.) Sorry, my KL Processor Reference is at home.
> The computer world used to be a much more interesting, if more
> confusing, place.
Agreed.
--
Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@]
MWOOD AT INDYVAX DOT IUPUI DOT EDU Finger for more information.
Thank goodness we've left behind the bad old days, before computers were
transformed from reliable business machines into performance art.
- Raw text -