What Makes an Architecture Bizarre?

[Quadibloc]

This NASA video on YouTube,

http://www.youtube.com/watch?v=nrwpXEiTDVk

shows what is apparently a maintenance console on a Control Data 3x00
computer at around 1:25 into the movie.

The normal console, though, doesn't quite match that of a 3400, 3600,
or 3800.

Anyways, in a search for more information, I came to a Wikipedia page
with a link to a PDF of a lecture from a series about "bizarre
architectures", which covered the Control Data 3600 and 6600. They
apparently were bizarre because they had 6-bit characters instead of 8-
bit characters.

I'll have to say that I found that hyperbolic.

John Savard

[nm...@cam.ac.uk]

In article <ecc55629-e3e1-4f05...@h17g2000yqe.googlegroups.com>,

Quadibloc <jsa...@ecn.ab.ca> wrote:
>
>Anyways, in a search for more information, I came to a Wikipedia page
>with a link to a PDF of a lecture from a series about "bizarre
>architectures", which covered the Control Data 3600 and 6600. They
>apparently were bizarre because they had 6-bit characters instead of 8-
>bit characters.
>
>I'll have to say that I found that hyperbolic.

6 bit characters were fairly widespread - the ICL 1900 had them, too,
in several variants.

The bizarrest ones I ever saw were ones that packed five 7-bit
characters. I once saw some program code that had been converted
from a (w.l.o.g.) 8-bit machine as binary and then written out
as characters. Problem: get it working on the original system,
starting from the printout. Not that hard, as it was Fortran with
very few multi-digit numbers.


Regards,
Nick Maclaren.

[jmfbahciv]

Quadibloc wrote:
> This NASA video on YouTube,
>
> http://www.youtube.com/watch?v=nrwpXEiTDVk
>
> shows what is apparently a maintenance console on a Control Data 3x00
> computer at around 1:25 into the movie.
>
> The normal console, though, doesn't quite match that of a 3400, 3600,
> or 3800.
>

> Anyways, in a search for more information, I came to a Wikipedia page
> with a link to a PDF of a lecture from a series about "bizarre
> architectures", which covered the Control Data 3600 and 6600. They
> apparently were bizarre because they had 6-bit characters instead of 8-
> bit characters.
>
> I'll have to say that I found that hyperbolic.

Which ties nicely to the Wiki thread and how wrong it can be.

/BAH

[jmfbahciv]

Morten Reistad wrote:

> In article <kgnmm4$au3$1...@needham.csi.cam.ac.uk>, <nm...@cam.ac.uk> wrote:
>>In article
<ecc55629-e3e1-4f05...@h17g2000yqe.googlegroups.com>,
>>Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>

>>>Anyways, in a search for more information, I came to a Wikipedia page
>>>with a link to a PDF of a lecture from a series about "bizarre
>>>architectures", which covered the Control Data 3600 and 6600. They
>>>apparently were bizarre because they had 6-bit characters instead of 8-
>>>bit characters.
>>>
>>>I'll have to say that I found that hyperbolic.
>>

>>6 bit characters were fairly widespread - the ICL 1900 had them, too,
>>in several variants.
>>
>>The bizarrest ones I ever saw were ones that packed five 7-bit
>>characters. I once saw some program code that had been converted
>>from a (w.l.o.g.) 8-bit machine as binary and then written out
>>as characters. Problem: get it working on the original system,
>>starting from the printout. Not that hard, as it was Fortran with
>>very few multi-digit numbers.
>

> 7-bit ascii packet 5 to a (36-bit) word BIZARRE? That is how
> it is, on a PDP10. Some of us still run tops20, you know.

You also are using RADIX50, ASCII, SIXBIT, but probably not
Baudot unless you'er doing TTY stuff.

What I find odd is the hint that non-DEC types didn't use all
of the encodings.

/BAH

[Terje Mathisen]

nm...@cam.ac.uk wrote:
> 6 bit characters were fairly widespread - the ICL 1900 had them, too,
> in several variants.
>

Unisys had both 6 and 8 (or 9?) bit chars afair.

> The bizarrest ones I ever saw were ones that packed five 7-bit
> characters. I once saw some program code that had been converted
> from a (w.l.o.g.) 8-bit machine as binary and then written out
> as characters. Problem: get it working on the original system,
> starting from the printout. Not that hard, as it was Fortran with
> very few multi-digit numbers.

Please explain:

Did you have the original source code stored as 5 letters per 36 bit
word and 10 letters in 72 bits, then those 72 bits had been split into 9
8-bit bytes in the printout?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[hanc...@bbs.cpcn.com]

On Feb 28, 8:26 am, Quadibloc <jsav...@ecn.ab.ca> wrote:

> Anyways, in a search for more information, I came to a Wikipedia page
> with a link to a PDF of a lecture from a series about "bizarre
> architectures", which covered the Control Data 3600 and 6600. They
> apparently were bizarre because they had 6-bit characters instead of 8-
> bit characters.

I thought the CDC machines had a 60 bit word.

6 bit characters were once common--the 14xx series used them. Indeed,
there was a debate during design of System/360 over whether to use 6
or 8 bit characters. Blaauw sought 8 bits, Amdahl sort 6 bits.
(IBM's 360, pp 148-149).

[Andrew Swallow]

On most computers most programmers only used the keyboard characters -
numbers, upper-case, lower-case, the printing symbols plus <space>,
<new_line>, <carriage_return> and <bell>. The line printer programmer
may use <null> and <Form_feed>.

In COBOL numbers could be stored in binary and binary_coded_decimal. A
core dump may use octal and hex.

The EBCDIC and ASCII character computers rarely needed to use other
coding systems unless they were talking to a different make of computer.

Andrew Swallow

[Tom Gardner]

Yes indeed, or maybe it is just a lack of imagination.

I rather like machines with a 39-bit word and two instructions per word.
Power of two? Even number of bits? Pah.

I believe there's a working Elliott 803 at Bletchley Park. Must go and
pay my respects sometime.

[nm...@cam.ac.uk]

In article <ak840a-...@ntp-sure.tmsw.no>,

Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
>> The bizarrest ones I ever saw were ones that packed five 7-bit
>> characters. I once saw some program code that had been converted
>> from a (w.l.o.g.) 8-bit machine as binary and then written out
>> as characters. Problem: get it working on the original system,
>> starting from the printout. Not that hard, as it was Fortran with
>> very few multi-digit numbers.
>
>Please explain:
>
>Did you have the original source code stored as 5 letters per 36 bit
>word and 10 letters in 72 bits, then those 72 bits had been split into 9
>8-bit bytes in the printout?

I no longer remember! All I can remember is that one character in
4 or 5 had lost a bit. It was done by some of my colleagues, and
they showed it to me as someone who might be amused.


Regards,
Nick Maclaren.

[Shmuel Metz]

In <kgnmm4$au3$1...@needham.csi.cam.ac.uk>, on 02/28/2013

at 01:39 PM, nm...@cam.ac.uk said:

>The bizarrest ones I ever saw were ones that packed five 7-bit
>characters.

Why is it bizarre for a 36-bit machine to store 5 ASCII characters in
a word? The alternative of storing 4 9-bit bytes in the word wastes
space, since ASCII is only 7 bits.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Stephen Fuld]

On 2/28/2013 7:10 AM, Terje Mathisen wrote:
> nm...@cam.ac.uk wrote:
>> 6 bit characters were fairly widespread - the ICL 1900 had them, too,
>> in several variants.
>>
>
> Unisys had both 6 and 8 (or 9?) bit chars afair.

Yes. Well, actually only the Univac part of Unisys. It was (and its
descendants still are) a 36 bit word oriented machine. That is, each
memory address referred to a 36 bit word. To access "characters", the
hardware provided a field within the instructions that allowed access to
"partial words". The original systems supported 6 bit characters, as
was common in that era. One accessed them by specifying which "sixth"
of the word one wanted to deal with. So, for example, you could load
"s1", the first sixth, which loaded the high order six bits of a 36 bit
word in memory into a register. There is also the ability to deal with
other partial words, thirds (12 bits) and halves (18 bits) all on the
natural boundaries.

Note that through some innovative engineering, there was no need for
read before write to store partial words (at least until the core was
replaced with DRAM and ECC was added. But by then the software expected
the hardware to "just do it", so you could do a partial word store and
the software would do the RBW behind the scenes for you.

Later, when it became important to support ASCII, the designers faced
the problem of how to provide support in a backward compatible way. The
came pretty close by adding support for dealing with "quarter words".
They stored an eight bit character in a nine bit field, with the high
order bit not used. They added additional hardware partial word
designators to allow dealing with the quarter words (Q1-Q4). But lots
of existing software still dealt with things in the original 6 bit code,
so the hardware supported both sixths and quarters of the same 36 bit
word. And so it exists still today.

I have often told Unisys (and its predecessor companies) management that
their biggest failure was their inability to convince the world that 36
was an integral power of 2. :-(



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[Stephen Fuld]

On 2/28/2013 7:21 AM, Shmuel (Seymour J.) Metz wrote:
> In <kgnmm4$au3$1...@needham.csi.cam.ac.uk>, on 02/28/2013
> at 01:39 PM, nm...@cam.ac.uk said:
>
>> The bizarrest ones I ever saw were ones that packed five 7-bit
>> characters.
>
> Why is it bizarre for a 36-bit machine to store 5 ASCII characters in
> a word? The alternative of storing 4 9-bit bytes in the word wastes
> space, since ASCII is only 7 bits.

I wouldn't go as far as bizarre, but it is unusual in that it is
irregular. How did one handle arbitrary length "strings" of ASCII
characters. Did you have to do special coding to skip a bit every five
characters? Was there specific hardware support for this format to make
things easier?

[Raymond Wiker]

The PDP-10 had the bit-field operations ldb and dpb (which live on in
Common Lisp), and (probably) also a set of string processing functions
implemented in hardware.

Note that packing 5 7-bit characters to a 36-bit word is not *that*
much more complex than packing 4 8-bit characters in a 32-bit word -
they both require a little care to get good performance from string
processing.

[hanc...@bbs.cpcn.com]

On Feb 28, 11:16 am, Andrew Swallow <am.swal...@btinternet.com> wrote:

> In COBOL numbers could be stored in binary and binary_coded_decimal.  A
> core dump may use octal and hex.

In IBM COBOL, numbers could be _stored_ in four ways--binary, binary
floating point, packed decimal, or as characters. To do a calculation
with a number requires conversion from character to another format.
I've never seen floating point used in COBOL, though I'm sure someone
has used it. (Today's COBOL has some trig functions).

[nm...@cam.ac.uk]

But there are other wrinkles, too. Remember the date. Fortran
was the dominant scientific programming language, and had no
character type before 1977. Handling characters in integers is
tricky enough, without adding that.


Regards,
Nick Maclaren.

[Scott Lurndal]

Andrew Swallow <am.sw...@btinternet.com> writes:

>In COBOL numbers could be stored in binary and binary_coded_decimal. A
>core dump may use octal and hex.

For Burroughs Medium Systems, all numbers in COBOL were stored as either
BCD numbers or EBCDIC numbers (the processor would ignore the zone digit
during arithmetic operations on EBCDIC numbers and add it to the result
if the result was UA (Unsigned Alpha) instead of UN (Unsigned Numeric: BCD)).

>
>The EBCDIC and ASCII character computers rarely needed to use other
>coding systems unless they were talking to a different make of computer.

Burroughs B3500 had a processor toggle that would tell the processor to
interpret a byte as ASCII or EBCDIC (mainly for inserting zone digits). This
feature was removed from the B4900 on.

The I/O processor had a flag that would cause inbound and outbound data
transfers to be translated between EBCDIC and ASCII selectivly on each I/O
operation (used, for example, to talk to ASCII Block-mode terminals like the
TD830 or T-27).

scott

[Anton Ertl]

Quadibloc <jsa...@ecn.ab.ca> writes:
>Anyways, in a search for more information, I came to a Wikipedia page
>with a link to a PDF of a lecture from a series about "bizarre
>architectures", which covered the Control Data 3600 and 6600. They
>apparently were bizarre because they had 6-bit characters instead of 8-
>bit characters.
>
>I'll have to say that I found that hyperbolic.

Well, given an unspecified link in an unspecified Wikipedia page, I
have no basus for agreeing or disagreeing with your evaluation.

In any case, at the time of the CDC 6600 word-addresses machines with
subdivisions of words into any convenient byte counts were the norm,
so that wasn't bizarre at the time. The IBM S/360 introduced byte
addressing and the 8-bit byte, as discussed not too long ago; and the
PDP-11 then also chose byte addressing and 8-bit bytes, and the 8008
and 6800 as well; and this all led to byte addressing and 8-bit bytes
becoming a de-facto standard; there are still word-addressed machines
in embedded CPUs, though.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[nm...@cam.ac.uk]

In article <HgNXs.488269$ck1.3...@fed05.iad>,

Scott Lurndal <sl...@pacbell.net> wrote:
>>
>>The EBCDIC and ASCII character computers rarely needed to use other
>>coding systems unless they were talking to a different make of computer.
>
>Burroughs B3500 had a processor toggle that would tell the processor to
>interpret a byte as ASCII or EBCDIC (mainly for inserting zone digits). This
>feature was removed from the B4900 on.

So did (many? most?) of the System/360 (and System/370?) series.
Rumour has it that they had to fix the architecture before IBM
Galactic Headquarters took a decision to go with EBCDIC, and it
never had any firmware (let alone software) written to go with
it. Nobody knew what would happen if you turned it on :-)


Regards,
Nick Maclaren.

[Shmuel Metz]

In <ak840a-...@ntp-sure.tmsw.no>, on 02/28/2013

at 04:10 PM, Terje Mathisen <"terje.mathisen at tmsw.no"> said:

>Unisys had both 6 and 8 (or 9?) bit chars afair.

Burroughs used 6 on the B5000 series and 4, 6 or 8 on the B6500 line.

UNIVAC's 1108 (36 bit) line used 6 and 9; their 32-bit machines used
8. The 30-bit line and the older 36-bit line used 6. I believe the the
UNIVAC III also used 6.

AFAIK only the U1108 and B6500 lines are still supported; I don't know
whether Unisys initially carried other lines forward.

[Shmuel Metz]

In <PM0004D6C...@aca287e7.ipt.aol.com>, on 02/28/2013
at 02:37 PM, jmfbahciv <See....@aol.com> said:

>Welcome to PDP land.

Also IBM land, circa 1961.

[hanc...@bbs.cpcn.com]

On Feb 28, 11:28 am, Tom Gardner <spamj...@blueyonder.co.uk> wrote:

> I rather like machines with a 39-bit word and two instructions per word.
> Power of two? Even number of bits? Pah.

The Bendix* G-15 appears to have had a 29 bit word (28 for magnitude,
one for the sign).

http://bitsavers.informatik.uni-stuttgart.de/pdf/bendix/g-15/APR-01601-1_G15_Programming_Part1_Jul61.pdf


*Total trivia note: The manual gave a street address for Bendix. I
checked it out on google streetview and found that the building at
that address is now a rent-a-car facility. The area is close to the
airport, and it seems most stuff there is to serve the airport,
including big parking lots.

It can be interesting looking up such old corporate addresses on
streetview to see if the company is still there or what has replaced
it. For instance, in the 1950s IBM ran an ad touting how its tab
machines help a company called Camloc. They're still in business at
the same location--the facade of the building looks the same as in the
ad.

[John Levine]

>Tops20 shows it's seniority!

Oh, you youngsters.

>The external, linker-visible symbol table is in radix50. Process
>"names" are in sixbit. Text is in 7-bit ascii stuffed 5 to a word.

TOPS-10 and its predecessor the PDP-6 monitor used sixbit file names,
7-bit ASCII text in files, and radix50 in object file symbol tables.
We dealt with it.

We all remember what the low bit in a word of 7-bit ASCII was, don't we?

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[hanc...@bbs.cpcn.com]

On Feb 28, 1:25 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> The IBM S/360 introduced byte
> addressing and the 8-bit byte,

While the byte was the basic working unit of the IBM S/360 family, one
could address storage as either bytes or words (half word, word,
doubleword). The general registers held 16 bits and there were
floating point registers.

[hanc...@bbs.cpcn.com]

On Feb 28, 11:51 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid>
wrote:

> On 2/28/2013 7:21 AM, Shmuel (Seymour J.) Metz wrote:
>

> > In <kgnmm4$au...@needham.csi.cam.ac.uk>, on 02/28/2013

[Quadibloc]

On Feb 28, 9:51 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

> I wouldn't go as far as bizarre, but it is unusual in that it is
> irregular.  How did one handle arbitrary length "strings" of ASCII
> characters.  Did you have to do special coding to skip a bit every five
> characters?  Was there specific hardware support for this format to make
> things easier?

The fact that five ASCII characters left a bit unused in a 36-bit word
would not, of itself, have required additional special coding. In
general, characters tended not to get special support in computers of
that vintage, and so one has to advance to the next word after every
few characters, and move through the word character by character.

It's not as if bit-field instructions were common in computers of that
vintage. They would have been scientific, not commercial, computers.

John Savard

[Quadibloc]

On Feb 28, 10:47 am, n...@cam.ac.uk wrote:

> But there are other wrinkles, too.  Remember the date.  Fortran
> was the dominant scientific programming language, and had no
> character type before 1977.  Handling characters in integers is
> tricky enough, without adding that.

Fortran programs would be stuck with six-bit characters until somebody
gave them new assembly-language subroutines to use the new longer
characters instead.

John Savard

[Anne & Lynn Wheeler]

nm...@cam.ac.uk writes:
> So did (many? most?) of the System/360 (and System/370?) series.
> Rumour has it that they had to fix the architecture before IBM
> Galactic Headquarters took a decision to go with EBCDIC, and it
> never had any firmware (let alone software) written to go with
> it. Nobody knew what would happen if you turned it on :-)

recent discussion of 360 ascii in mainframe mailing list
http://www.garlic.com/~lynn/2013b.html#72 One reasonf or monocase was Re: Dualcase vs monocase
http://www.garlic.com/~lynn/2013b.html#73 One reasonf or monocase was Re: Dualcase vs monocase

"The Biggest Computer Goof Ever":
http://www.bobbemer.com/P-BIT.HTM

from above:

I mention this because it is a classic software mistake. IBM was going
to announce the 360 in 1964 April as an ASCII machine, but their
printers and punches were not ready to handle ASCII, and IBM just HAD to
announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
had a store of spendable money. They put in the P-bit. Set one way, it
ran in EBCDIC. Set the other way, it ran in ASCII.

But nobody told the programmers, like a Chinese Army in numbers! They
spent this huge amount of money to make software in which EBCDIC
encodings were used in the logic. Reverse the P-bit, to work in ASCII,
and it died. And they just could not spend that much money again to redo
it.

.... snip ... and (one of the Consequences):

Although some IBM customers would stay with all upper case for a while,
the introduction of lower case would destroy all collating precedent,
and IBM knew that, too. Especially from the STRETCH design in 1958,
where I made a big mistake in setting the collating sequence as
"A-a-B-b-C ..." [2]. Ordering alphabetically in dual case must be a
two-step process -- first on the letter itself, and then on the quality
of the letter (its case).

... snip ...

IBM ASCII reference also mentions getting collating sequence wrong in
STRETCH

--
virtualization experience starting Jan1968, online at home since Mar1970

[Quadibloc]

On Feb 28, 8:49 am, hanco...@bbs.cpcn.com wrote:
> On Feb 28, 8:26 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
>
> > Anyways, in a search for more information, I came to a Wikipedia page
> > with a link to a PDF of a lecture from a series about "bizarre
> > architectures", which covered the Control Data 3600 and 6600. They
> > apparently were bizarre because they had 6-bit characters instead of 8-
> > bit characters.
>
> I thought the CDC machines had a 60 bit word.

Yes, the 6600 had a 60-bit word of ten 6-bit characters, and the 3600
had a 48-bit word of eight 6-bit characters.

John Savard

[John Levine]

>> The IBM S/360 introduced byte addressing and the 8-bit byte,
>
>While the byte was the basic working unit of the IBM S/360 family, one
>could address storage as either bytes or words (half word, word,
>doubleword). The general registers held 16 bits and there were
>floating point registers.

Not really. All addressing was byte addressing. There were halfword,
word, and doubleword instructions, whose operands had to have the low
bit, two bits, or three bits zero (a restriction later removed by the
370's byte aligned operaned feature.)

Except on the 360/20, the general registers were 32 bits.

[Quadibloc]

On Feb 28, 11:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> Well, given an unspecified link in an unspecified Wikipedia page, I
> have no basus for agreeing or disagreeing with your evaluation.

That's fair. Here's the page:

http://en.wikipedia.org/wiki/CDC_3000

and here's the link to an installment from the "Bizarre Architecture"
lecture series at the University of Massachussetts:

http://people.cs.umass.edu/~verts/cmpsci201/spr_2004/Lecture_33_2004-04-30_CDC-3300_and_6000.pdf

I think it's clear that since he was giving a week's worth of
lectures, he had to include computers that were mildly unconventional
by _today's_ standards in his list to pad it out.

To me, "bizarre" would have to mean something significantly
unconventional, not something that happened to use a basic storage
unit only large enough to hold the character set that people thought
computers needed back then.

John Savard

[Quadibloc]

Yes, but addresses were *in units of bytes* even if they had to be
aligned on halfword, word, or doubleword boundaries, and they referred
to objects of those lengths.

John Savard

[Quadibloc]

On Feb 28, 9:55 am, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> In <PM0004D6C9D6710...@aca287e7.ipt.aol.com>, on 02/28/2013

>    at 02:37 PM, jmfbahciv <See.ab...@aol.com> said:
>
> >Welcome to PDP land.
>
> Also IBM land, circa 1961.

6-bit characters, yes. Radix-40 or Radix-50 and things like that, no.

John Savard

[Quadibloc]

On Feb 28, 9:16 am, Andrew Swallow <am.swal...@btinternet.com> wrote:

> On most computers most programmers only used the keyboard characters -
> numbers, upper-case, lower-case, the printing symbols plus <space>,
> <new_line>, <carriage_return> and <bell>.  The line printer programmer
> may use <null> and <Form_feed>.

In the IBM world, applications programmers didn't deal with control
characters. All characters were treated as printable. If you had
variable length character strings, you indicated this with a length,
not a terminating character. If you wanted to tell a printer to double
space or overprint, you indicated that with the first character of the
line of text you sent to it.

John Savard

[Ivan Godard]

On 2/28/2013 11:06 AM, Quadibloc wrote:

>
> To me, "bizarre" would have to mean something significantly
> unconventional, not something that happened to use a basic storage
> unit only large enough to hold the character set that people thought
> computers needed back then.

One of my favorites was the Astranautics ZS-1, the first commercial
machine with a decoupled access-execute architecture. I put something
similar in the Harris Supercomputer, which sadly (for me; very wisely
for Harris) never got built.

Ivan

[hanc...@bbs.cpcn.com]

On Feb 28, 11:44 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid>
wrote:

> Later, when it became important to support ASCII, the designers faced
> the problem of how to provide support in a backward compatible way.  The
> came pretty close by adding support for dealing with "quarter words".
> They stored an eight bit character in a nine bit field, with the high
> order bit not used.  They added additional hardware partial word
> designators to allow dealing with the quarter words (Q1-Q4).  But lots
> of existing software still dealt with things in the original 6 bit code,
> so the hardware supported both sixths and quarters of the same 36 bit
> word.  And so it exists still today.

In April 1964 Western Union analyzed the then new ASCII code. They
saw it as seven bits, not eight (see link below pg 55). From a
communications they found it objectionable because (1) seven bits
would be harder for staff to remember than five bits and (2) the codes
have many 'one-bits' which would result in increased wear on
reperforators, relays, and transmitters.

http://massis.lcs.mit.edu/telecom-archives/archives/technical/western-union-tech-review/18-2/p050.htm

[hanc...@bbs.cpcn.com]

On Feb 28, 11:51 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid>
wrote:

> I wouldn't go as far as bizarre, but it is unusual in that it is
> irregular.  How did one handle arbitrary length "strings" of ASCII
> characters.  Did you have to do special coding to skip a bit every five
> characters?  Was there specific hardware support for this format to make
> things easier?

On the IBM 14xx line, which was intended for business processing and
had character addressing, there was an additional bit on every
character called a word mark. This would be set to define a boundary
of a string of characters.

From the 1401 General Information manual (see link below, pg 9):

Variable Word Length

Certain stored-program machines, of which the 1401
is an example, have a desirable characteristic called
"variable word length." The ability to have grouped
together any number of storage positions to accommodate
fields of any size, gives rise to this term. The
fact that a machine has variable word length allows
efficient use of the storage area.

It is recalled that on both the 604 and 602 [calculators] each
storage unit contains a specific number of positions;
each is fixed in length. For this reason, high-order
positions are frequently wasted because, in size, the
field is smaller than the unit. [In those days, core memory was still
very expensive, and wasted space was a significant issue, especially
in a lower priced machine.]

In a variable word length machine this does not
happen; there are no fixed groupings of storage positions.
Instead, the size of the grouping varies with
the length of the data or instruction field to be accommodated.

The word mark makes this possible; it
can be set to make any storage position the high-order
position. It can also be erased from storage positions
when field limits change.

http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/140x/F20-208_1401_GenInfo1959.pdf
page 9

[Terje Mathisen]

nm...@cam.ac.uk wrote:
> In article <ak840a-...@ntp-sure.tmsw.no>,

> Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>>
>>> The bizarrest ones I ever saw were ones that packed five 7-bit

>>> characters. I once saw some program code that had been converted
>>> from a (w.l.o.g.) 8-bit machine as binary and then written out
>>> as characters. Problem: get it working on the original system,
>>> starting from the printout. Not that hard, as it was Fortran with
>>> very few multi-digit numbers.
>>
>> Please explain:
>>
>> Did you have the original source code stored as 5 letters per 36 bit
>> word and 10 letters in 72 bits, then those 72 bits had been split into 9
>> 8-bit bytes in the printout?
>
> I no longer remember! All I can remember is that one character in
> 4 or 5 had lost a bit. It was done by some of my colleagues, and
> they showed it to me as someone who might be amused.

OK, I see what happened!

You had a binary (effectively) file with 36-bit words, it had been
printed as 5 7-bit chars/octals per word, dropping either the first or
last bit.

This meant that you had to guess what that last bit should be, and since
you could recover it was probably located as the top bit of the
corresponding byte/char.

(If it had been the bottom bit then you would have had no way to figure
out if a digit was 0 or 1, 2 or 3 etc, and those are very common in a
fortran source code.)

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[EricP]

Quadibloc wrote:
>
> To me, "bizarre" would have to mean something significantly
> unconventional, not something that happened to use a basic storage
> unit only large enough to hold the character set that people thought
> computers needed back then.

I think the RCA 1802's "set a register to select which general register
is the program counter (oh and leave out call and return instructions)"
certainly qualifies. I've never figured a reason that would possibly
justify this architecture decision.

call and ret do make the state sequencer more complicated,
but not that much more.

Also was just reading about the PDP 8's DCA Deposit (store to memory)
and Clear Accumulator instruction. If you did not want to clear
the accumulator, you had to add it back in again afterwards.

Eric

[Peter Flass]

On 2/28/2013 12:08 PM, Shmuel (Seymour J.) Metz wrote:
> In <ak840a-...@ntp-sure.tmsw.no>, on 02/28/2013
> at 04:10 PM, Terje Mathisen <"terje.mathisen at tmsw.no"> said:
>
>> Unisys had both 6 and 8 (or 9?) bit chars afair.
>
> Burroughs used 6 on the B5000 series and 4, 6 or 8 on the B6500 line.
>
> UNIVAC's 1108 (36 bit) line used 6 and 9;

6, 7, and 9 IIRC. Talk about weird architectures - they supported three
different character sets "Fielddata", which was originally used for
miltitary applications, and, I believe, both 7 and 8 bit ASCII. (Univac
1108).

--
Pete

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004D6C...@aca287e7.ipt.aol.com...
> Quadibloc wrote:
>> This NASA video on YouTube,
>>
>> http://www.youtube.com/watch?v=nrwpXEiTDVk
>>
>> shows what is apparently a maintenance console on a Control Data 3x00
>> computer at around 1:25 into the movie.
>>
>> The normal console, though, doesn't quite match that of a 3400, 3600,
>> or 3800.

>>
>> Anyways, in a search for more information, I came to a Wikipedia page
>> with a link to a PDF of a lecture from a series about "bizarre
>> architectures", which covered the Control Data 3600 and 6600. They
>> apparently were bizarre because they had 6-bit characters instead of 8-
>> bit characters.
>>

>> I'll have to say that I found that hyperbolic.
>

> Which ties nicely to the Wiki thread and how wrong it can be.

But it still leaves what we had to use before it for dead on update
frequency alone.

[Peter Flass]

CTG's original headquarters is now (IIRC) an insurance agency and other
stuff. I think their current HQ is the old IBM office on Delaware Avenue
in Buffalo.



--
Pete

[Peter Flass]

On 2/28/2013 2:00 PM, Anne & Lynn Wheeler wrote:
>
> nm...@cam.ac.uk writes:
>> So did (many? most?) of the System/360 (and System/370?) series.
>> Rumour has it that they had to fix the architecture before IBM
>> Galactic Headquarters took a decision to go with EBCDIC, and it
>> never had any firmware (let alone software) written to go with
>> it. Nobody knew what would happen if you turned it on :-)
>
> recent discussion of 360 ascii in mainframe mailing list
> http://www.garlic.com/~lynn/2013b.html#72 One reasonf or monocase was Re: Dualcase vs monocase
> http://www.garlic.com/~lynn/2013b.html#73 One reasonf or monocase was Re: Dualcase vs monocase
>
> "The Biggest Computer Goof Ever":
> http://www.bobbemer.com/P-BIT.HTM
>
> from above:
>
> I mention this because it is a classic software mistake. IBM was going
> to announce the 360 in 1964 April as an ASCII machine, but their
> printers and punches were not ready to handle ASCII, and IBM just HAD to
> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
> had a store of spendable money. They put in the P-bit. Set one way, it
> ran in EBCDIC. Set the other way, it ran in ASCII.

I've never been clear exactly what this would have done. A character is
just an n-bit chunk with no intrinsic interpretation. It only becomes a
character when it is printed, or punched.

--
Pete

[Stephen Fuld]

On 2/28/2013 10:59 AM, Quadbloc wrote:
> On Feb 28, 9:51 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
>
>> I wouldn't go as far as bizarre, but it is unusual in that it is
>> irregular. How did one handle arbitrary length "strings" of ASCII
>> characters. Did you have to do special coding to skip a bit every five
>> characters? Was there specific hardware support for this format to make
>> things easier?
>
> The fact that five ASCII characters left a bit unused in a 36-bit word
> would not, of itself, have required additional special coding. In
> general, characters tended not to get special support in computers of
> that vintage, and so one has to advance to the next word after every
> few characters, and move through the word character by character.

Well, the 1108 was released in about 1964, far before the PDP 10 and it
had some hardware support for characters (see my earlier post). Even
though it had that support, and the encoding was more "regular") dealing
with arbitrary length strings was messy. But if you had arbitrary bit
extract/insert instructions as Raymond Wiker has posted, then it
wouldn't bee so bad. But again, the PDP 10 was long after the 1108.

> It's not as if bit-field instructions were common in computers of that
> vintage. They would have been scientific, not commercial, computers.

BTW, the 1108s I worked on in the 1970s were mostly programmed in COBOL,
not Fortran, but that's a different story.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[Peter Flass]

I thought the -8 was bizarre in general, justified only by it's use of
discrete transistor logic.


--
Pete

[nm...@cam.ac.uk]

In article <kgoe2g$23o$3...@dont-email.me>,

Er, no, not on that architecture. There were some instructions
that translated to and from characters.



Regards,
Nick Maclaren.

[Dan Espen]

What makes an architecture bizarre? Meetings.

--
Dan Espen

[Patrick Scheible]

nm...@cam.ac.uk writes:

> In article <ecc55629-e3e1-4f05...@h17g2000yqe.googlegroups.com>,

> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>
>>Anyways, in a search for more information, I came to a Wikipedia page
>>with a link to a PDF of a lecture from a series about "bizarre
>>architectures", which covered the Control Data 3600 and 6600. They
>>apparently were bizarre because they had 6-bit characters instead of 8-
>>bit characters.
>>
>>I'll have to say that I found that hyperbolic.
>

> 6 bit characters were fairly widespread - the ICL 1900 had them, too,
> in several variants.

>
> The bizarrest ones I ever saw were ones that packed five 7-bit
> characters. I once saw some program code that had been converted
> from a (w.l.o.g.) 8-bit machine as binary and then written out
> as characters. Problem: get it working on the original system,
> starting from the printout. Not that hard, as it was Fortran with
> very few multi-digit numbers.

7-bit characters aren't bizarre at all. ASCII is a 7-bit code.
Stands to reason that back when Men were Men and memory spaces were
precious, they'd be packed. Same comment about sixbit, it's enough for
uppercase and digits and symbols, and for many purposes that's all you
need.

-- Patrick

[Scott Lurndal]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>In <ak840a-...@ntp-sure.tmsw.no>, on 02/28/2013
> at 04:10 PM, Terje Mathisen <"terje.mathisen at tmsw.no"> said:
>
>>Unisys had both 6 and 8 (or 9?) bit chars afair.
>
>Burroughs used 6 on the B5000 series and 4, 6 or 8 on the B6500 line.

and 8 on the B3500 (medium systems) line. FWIW, B5000 is considered
an ancestor of the B6500 (with the B5500 derived from the B5000 and
the B6500 a tredy-designed larger B5500) (I supposed like the PDP-6 and PDP-10?).

Thereafter, the large systems designs alternated between southern cal and
tredyffrin Pa.

>
>UNIVAC's 1108 (36 bit) line used 6 and 9; their 32-bit machines used
>8. The 30-bit line and the older 36-bit line used 6. I believe the the
>UNIVAC III also used 6.
>
>AFAIK only the U1108 and B6500 lines are still supported; I don't know
>whether Unisys initially carried other lines forward.

The merger was in 86. The V-series (nee Medium Systems) line was discontinued
around 1991 (and support EOL'd 12/31/1999). The small systems (B1900) line
had been discontinued prior to the merger. CP9500 lived on for a while, but
probably not much past 1990.

The System/80 line on the Sperry side was discontinued right after the
merger, if I recall correctly.

Two lines still exist, one based on the Sperry 2200 (Clearpath Dorado) and the other
on the Burroughs A-Series (Clearpath Libra) (A-series were followons to the B[567]900).

scott

[Scott Lurndal]

When you read in a 80-column card with numeric values, the EBCDIC digits
are stored as F0-F9, but ASCII are stored as 30-39. ASCII software
would expect 30, EBCDIC software F0. Likewise for most other symbols.

The collating sequence also is quite different.

I would have though it would have been less expensive for IBM to just put some
translation hardware in the control unit or I/O susbystem rather than adding
the "P" bit.

scott

[Scott Lurndal]

Last I was there, the Burroughs Pasadena facility (Electrodata in the 50's,
sold by Unisys in 1992) is now NASA/JPL on the ground floor, and a 24-hour
fitness in the basement.

http://maps.google.com/?ll=34.154352,-118.081647&spn=0.001676,0.001996&t=m&z=19&layer=c&cbll=34.154539,-118.081963&panoid=lQY0zha2n3bciFWUcIGJPA&cbp=12,74.68,,0,0.48

scott

[Patrick Scheible]

Stephen Fuld <SF...@alumni.cmu.edu.invalid> writes:

> On 2/28/2013 7:21 AM, Shmuel (Seymour J.) Metz wrote:
>> In <kgnmm4$au3$1...@needham.csi.cam.ac.uk>, on 02/28/2013

>> at 01:39 PM, nm...@cam.ac.uk said:
>>
>>> The bizarrest ones I ever saw were ones that packed five 7-bit
>>> characters.
>>

>> Why is it bizarre for a 36-bit machine to store 5 ASCII characters in
>> a word? The alternative of storing 4 9-bit bytes in the word wastes
>> space, since ASCII is only 7 bits.

>
> I wouldn't go as far as bizarre, but it is unusual in that it is
> irregular. How did one handle arbitrary length "strings" of ASCII
> characters. Did you have to do special coding to skip a bit every
> five characters? Was there specific hardware support for this format
> to make things easier?

On the PDP-10 there are instructions to pack and unpack any length of
byte from words. I'm sure other word-oriented machines had them as
well.

-- Patrick

[Patrick Scheible]

John Levine <jo...@iecc.com> writes:

>>Tops20 shows it's seniority!
>
> Oh, you youngsters.
>
>>The external, linker-visible symbol table is in radix50. Process
>>"names" are in sixbit. Text is in 7-bit ascii stuffed 5 to a word.
>
> TOPS-10 and its predecessor the PDP-6 monitor used sixbit file names,
> 7-bit ASCII text in files, and radix50 in object file symbol tables.
> We dealt with it.
>
> We all remember what the low bit in a word of 7-bit ASCII was, don't we?

It makes sense. When bits are precious, you don't use more of them than
you have to. Editing text files, people needed lowercase, but lowercase
wasn't used in monitor commands or symbol tables.

-- Patrick

[Patrick Scheible]

hanc...@bbs.cpcn.com writes:

> On Feb 28, 8:26 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
>
>> Anyways, in a search for more information, I came to a Wikipedia page
>> with a link to a PDF of a lecture from a series about "bizarre
>> architectures", which covered the Control Data 3600 and 6600. They
>> apparently were bizarre because they had 6-bit characters instead of 8-
>> bit characters.
>

> I thought the CDC machines had a 60 bit word.
>
> 6 bit characters were once common--the 14xx series used them. Indeed,
> there was a debate during design of System/360 over whether to use 6
> or 8 bit characters. Blaauw sought 8 bits, Amdahl sort 6 bits.
> (IBM's 360, pp 148-149).

They should have compromised and used 7 :)

-- Patrick

[Patrick Scheible]

Tom Gardner <spam...@blueyonder.co.uk> writes:

> Quadibloc wrote:
>> This NASA video on YouTube,
>>
>> http://www.youtube.com/watch?v=nrwpXEiTDVk
>>
>> shows what is apparently a maintenance console on a Control Data 3x00
>> computer at around 1:25 into the movie.
>>
>> The normal console, though, doesn't quite match that of a 3400, 3600,
>> or 3800.
>>

>> Anyways, in a search for more information, I came to a Wikipedia page
>> with a link to a PDF of a lecture from a series about "bizarre
>> architectures", which covered the Control Data 3600 and 6600. They
>> apparently were bizarre because they had 6-bit characters instead of 8-
>> bit characters.
>>

>> I'll have to say that I found that hyperbolic.
>

> Yes indeed, or maybe it is just a lack of imagination.

>
> I rather like machines with a 39-bit word and two instructions per word.

Are there real machines like that? 19 bits per instruction and one
extra bit?

-- Patrick

[Stephen Fuld]

How about when it is input from a device such as punched card reader or
a terminal? You really want to know, for example, whether numbers
collate higher or lower than characters.

[Stephen Fuld]

AFAICR the 1108 never supported 7 bit ASCII. But yes, the six bit code
was Fieldata, not BCD.

[Bill Findlay]

On 28/02/2013 21:26, in article 86obf4d...@chai.my.domain, "Patrick
Scheible" <k...@zipcon.net> wrote:

> Tom Gardner <spam...@blueyonder.co.uk> writes:
>...

>>
>> Yes indeed, or maybe it is just a lack of imagination.
>>
>> I rather like machines with a 39-bit word and two instructions per word.
>
> Are there real machines like that? 19 bits per instruction and one
> extra bit?

Yes, the Elliott 803A/B and 503.

If the extra bit was set, the operand of the first instruction in the word
acted as a modifier on the effective address of the second instruction.

Elliott computers were all quite ... eccentric.

--
Bill Findlay
with blueyonder.co.uk;
use surname & forename;

[Ivan Godard]

On 2/27/2013 1:31 PM, Scott Lurndal wrote:

> Last I was there, the Burroughs Pasadena facility (Electrodata in the 50's,
> sold by Unisys in 1992) is now NASA/JPL on the ground floor, and a 24-hour
> fitness in the basement.
>
> http://maps.google.com/?ll=34.154352,-118.081647&spn=0.001676,0.001996&t=m&z=19&layer=c&cbll=34.154539,-118.081963&panoid=lQY0zha2n3bciFWUcIGJPA&cbp=12,74.68,,0,0.48

I wrote my first compiler in that building.

Ivan

[Ivan Godard]

On 2/27/2013 1:20 PM, Scott Lurndal wrote:
> Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
>> In <ak840a-...@ntp-sure.tmsw.no>, on 02/28/2013
>> at 04:10 PM, Terje Mathisen <"terje.mathisen at tmsw.no"> said:
>>
>>> Unisys had both 6 and 8 (or 9?) bit chars afair.
>>
>> Burroughs used 6 on the B5000 series and 4, 6 or 8 on the B6500 line.
>
> and 8 on the B3500 (medium systems) line. FWIW, B5000 is considered
> an ancestor of the B6500 (with the B5500 derived from the B5000 and
> the B6500 a tredy-designed larger B5500) (I supposed like the PDP-6 and PDP-10?).
>
> Thereafter, the large systems designs alternated between southern cal and
> tredyffrin Pa.

Nope, you're thinking of the B8500 which was a Pennsylvania disaster.
The B6500 was done in Pasadena. I was there :-)

[Tom Gardner]

Yup, as I indicated, the Elliott 803.

To tie in with the other sub-thread, it used 5bit teletypes
for human i/o; the interesting characters were figure-shift
and letter-shift which specified that later characters were
figures/symbols or letters respectively.

Online storage used magnetic *film*, effectively 35mm wide
sprocketed magnetic tape. The designers were just down the
road from Borehamwood movie studios and their associated
film processing industries.

[Mark Thorson]

nm...@cam.ac.uk wrote:
>
> In article <HgNXs.488269$ck1.3...@fed05.iad>,
> Scott Lurndal <sl...@pacbell.net> wrote:
> >>
> >>The EBCDIC and ASCII character computers rarely needed to use other
> >>coding systems unless they were talking to a different make of computer.
> >
> >Burroughs B3500 had a processor toggle that would tell the processor to
> >interpret a byte as ASCII or EBCDIC (mainly for inserting zone digits). This
> >feature was removed from the B4900 on.

>
> So did (many? most?) of the System/360 (and System/370?) series.
> Rumour has it that they had to fix the architecture before IBM
> Galactic Headquarters took a decision to go with EBCDIC, and it
> never had any firmware (let alone software) written to go with
> it. Nobody knew what would happen if you turned it on :-)

The story of that decision is here:

http://www.bobbemer.com/P-BIT.HTM

[John Levine]

>On the PDP-10 there are instructions to pack and unpack any length of
>byte from words.

Yes.

> I'm sure other word-oriented machines had them as well.

No. The GE 635/645 (the Multics machine), for example, could pack and
unpack 6 or 9 bit bytes, but for any other size you had to do your own
shifting and masking.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Peter Flass]

Yes, but this is done by the control unit (as you allude later) and the
P bit has no effect on what is stored.

>
> The collating sequence also is quite different.

True, but again irrelevant to the P bit, I believe.

I think the bit had some part in what signs were used for packed decimal
data, and probably the operation of the PACK and UNPK instructions.

>
> I would have though it would have been less expensive for IBM to just put some
> translation hardware in the control unit or I/O susbystem rather than adding
> the "P" bit.
>

--
Pete

[Anne & Lynn Wheeler]

Peter Flass <Peter...@Yahoo.com> writes:
> Yes, but this is done by the control unit (as you allude later) and
> the P bit has no effect on what is stored.

re:
http://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?

there was actually a different kind of problem involving IBM termianls
and ASCII terminals.

IBM terminals weren't ebcdic ... and so terminal data had to be
translated back&forth between terminal bit pattern and ebcdic bit
pattern.

when cp67 was delivered to the univ, it had 1052 & 2741 terminal support
(with appropriate translate tables). The univ had some number of
tty/ascii terminals and I added tty/ascii terminal support and the
appropriate translate tables ... the issue was that there are some chars
in ascii that aren't in ebcdic as well as the reverse ... so there was
some issues of mapping ascii characters (not defined in ebcdic) to
something ... as well mapping some ebcdic characters (not defined in
ascii) to something.

the other issue was that cp67 code as delivered did automatic terminal
type identification ... and dynamically changed the terminal controller
line-scanner to the appropriate one for that kind of terminal. when I
added tty/ascii support ... I extended the automatic terminal type
processing to include tty/ascii. I actually tried to have a single
dial-in number (for all types of dialup terminals; with common
hunt-group ... pool of numbers and corresponding controller port
connections). it turned out that they had taken some sort cuts in the
ibm terminal controller ... while it was possibly to dynamicall change
the terminal type line-scanner for each controller port ... they
hard-wired each port line-speed. It wasn't problem for common pool for
1052 & 2741 terminals since they operated at the same line speed ...
but it was a problem for tty/ascii which operated at different line
speed.

this was part of the motivation for the univ to start a clone controller
project, started with interdata/3 programmed to emulate the ibm terminal
controller (but supporting adapting both the port line scanner as well
as the port line speed) ... as building a controller channel I/O
interface board for the interdata/3 (later it evolved into an
interdata/4 for the channel interface with pool of interdata/3s for
handling ports). early bug was data arriving in 360 memory all garbled
... it turns out that the ibm terminal controller convention was to
place the arriving leading bit in the low-order bit position in the byte
and the fill the byte in reverse direction as the bits arrived ... then
transmit each byte to 360 memory (so bits within byte were in reverse
order of arrival). The initial testing with interdata/3 had bits in the
byte in bit arrival order (not reverse order) ... aka 360 terminal
standard had terminal/line ascii in bit-reversed order.

later, four of us are written up as being responsible for (some part of)
ibm clone controller business. ... some past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

later still, the folklore is that major motivation for IBM's Future
System effort (completely replace 360 with something radically
different) was to make the controller interface so complex that it would
be a barrier to clone controller business. misc. past posts mentioning
(failed) future system
http://www.garlic.com/~lynn/submain.html#futuresys

The rise and fall of IBM
http://www.ecole.org/en/seances/CM07

from above:

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead that
the competition would never be able to keep up, and to have such a high
level of integration that it would be impossible for competitors to
follow a compatible niche strategy. However, the project failed because
the objectives were too ambitious for the available technology. Many of
the ideas that were developed were nevertheless adapted for later
generations. Once IBM had acknowledged this failure, it launched its
'box strategy', which called for competitiveness with all the different
types of compatible sub-systems.

... snip ...

actually lots of FS was pure blue sky more like vaporware

--
virtualization experience starting Jan1968, online at home since Mar1970

[hanc...@bbs.cpcn.com]

On Feb 28, 3:59 pm, Patrick Scheible <k...@zipcon.net> wrote:

> 7-bit characters aren't bizarre at all.  ASCII is a 7-bit code.
> Stands to reason that back when Men were Men and memory spaces were
> precious, they'd be packed.  Same comment about sixbit, it's enough for
> uppercase and digits and symbols, and for many purposes that's all you
> need.

Some applications had computer generated letters or messages. Often
they used a generic letterhead or plain white paper, but were
generated by the line printer in all caps. A bunch of text
information presented that way is very hard to read, especially single
spaced.

What was sad was that once it became easy to enter and print lower
case letters (via better terminals and xerographic printers in the mid
1980s), many organizations didn't bother upgrading their programs, and
they continued to print in all caps.

[Quadibloc]

On Feb 28, 12:49 pm, EricP <ThatWouldBeTell...@thevillage.com> wrote:

> Also was just reading about the PDP 8's DCA Deposit (store to memory)
> and Clear Accumulator instruction. If you did not want to clear
> the accumulator, you had to add it back in again afterwards.

That was its one eccentricity, explained by the need to reserve an
opcode for I/O: TAD and DCA let you do everything you could do with
TAD, LDA, and STO. (It was TAD instead of ADD for historical reasons:
the PDP-9 and its relatives had opcodes for both one's complement and
two's complement arithmetic. Now, _that's_ weird.)

John Savard

[hanc...@bbs.cpcn.com]

On Feb 27, 4:20 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:

> Thereafter, the large systems designs alternated between southern cal and
> tredyffrin Pa.

I was about to ask if that arrangement wasn't very inefficient. But
then I recalled that IBM assigned one model of System/360 to an
English town (Helmsley?) Somewhere I read that IBM set up an overseas
private line to interconnect its locations. Back then that was
enormously expensive.

BTW, Tredyffrin PA is fairly close to Blue Bell, PA, where Univac's HQ
was, about a 20 minute drive. These are all suburbs of
Philadelphia. IIRC, both pre-merger Univac and Burroughs had several
office locations in that area, including Paoli, PA, and King of
Prussia, PA.


IIRC, RCA divided work between Cherry Hill, NJ, and Boston, sometimes
swapping assignments, which did not help its situation.

[hanc...@bbs.cpcn.com]

On Feb 28, 4:32 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

> How about when it is input from a device such as punched card reader or
> a terminal?  You really want to know, for example, whether numbers
> collate higher or lower than characters.

The collating sequence on a punched card is tricky because numbers are
represented one a single punch while letters are represented by two
punches. IBM machines had/have instructions to move just the 'zone'
or the 'numeric' internally.

If you're sorting the cards on a card sorter, you would need two
passes for alpha data. Since numeric data does not have a zone punch
(unless it's signed), it would be a space and show up on top.

As to terminal entry, what counts is how the entry is ultimately
stored in the machine.

On IBM mainframes, when sorting, one specifies the format of the data--
character, packed decimal, binary, etc.

[Shmuel Metz]

In <kgolv5$h3k$2...@dont-email.me>, on 02/28/2013

at 02:34 PM, Ivan Godard <iv...@ootbcomp.com> said:

>Nope, you're thinking of the B8500 which was a Pennsylvania disaster.

When record companies were sending Paoli to radio stations to play
their songs <g, d & r>.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <861uc0f...@chai.my.domain>, on 02/28/2013

at 01:19 PM, Patrick Scheible <k...@zipcon.net> said:

>On the PDP-10 there are instructions to pack and unpack any length of
>byte from words. I'm sure other word-oriented machines had them as
>well.

The VFL unit of the IBM 7030 could handle byte strings with bytes that
crossed word boundaries; the CDC 3600 and 3800 could access single
byte. The B1700 also had byte handling features, but I don't know the
details. I believe that the EIS in GE HoneyBull also had limited byte
handling capability.

[Shmuel Metz]

In <YMuXs.19513$DO....@fe40.iad>, on 02/27/2013

at 09:20 PM, sc...@slp53.sl.home (Scott Lurndal) said:

>and 8 on the B3500 (medium systems) line. FWIW, B5000 is
>considered an ancestor of the B6500

FSVO ancestor.

>(with the B5500 derived from the B5000 and
>the B6500 a tredy-designed larger B5500)

Not even close. The B5000, B5500 and B5700 have a common architecture;
the B6500 is a totally new design.

What was the fate of the UNIVAC 490 line?

[Shmuel Metz]

In <kgodiu$23o$1...@dont-email.me>, on 02/28/2013

at 03:18 PM, Peter Flass <Peter...@Yahoo.com> said:

>6, 7, and 9 IIRC.

No. The j field[1] can specify a word, one of two 18-bit bytes, one of
three 12-bit bytes, one of four 9-bit bytes or one of six 6-bit bytes.

>they supported three different character sets

The character set is not part of the architecture. I consider the
UNIVAC 1108 to be rather conventional compared to, e.g., Bendix G-20,
RCA 601.

[1] Possibly modified by the quarter word designator.

[Shmuel Metz]

In <kgo87g$cod$1...@needham.csi.cam.ac.uk>, on 02/28/2013

at 06:38 PM, nm...@cam.ac.uk said:

>In article <HgNXs.488269$ck1.3...@fed05.iad>,
>Scott Lurndal <sl...@pacbell.net> wrote:
>>>
>>>The EBCDIC and ASCII character computers rarely needed to use other
>>>coding systems unless they were talking to a different make of computer.
>>
>>Burroughs B3500 had a processor toggle that would tell the processor to
>>interpret a byte as ASCII or EBCDIC (mainly for inserting zone digits). This
>>feature was removed from the B4900 on.

>So did (many? most?) of the System/360 (and System/370?) series.

No; the S/360 had a PSW bit, not a toggle swiotch, and the S/370 had
neither.

>Rumour has it that they had to fix the architecture before IBM
>Galactic Headquarters took a decision to go with EBCDIC, and it
>never had any firmware (let alone software) written to go with it.
>Nobody knew what would happen if you turned it on :-)

That's the first I've heard of it. Given IBM's attitude towards the
architecture specifications, I'd be very surprised if it wasn't tested
thoroughly. What is true is that IBM didn't release an OS that
supported the ASCII bit.

[Shmuel Metz]

In <2013Feb2...@mips.complang.tuwien.ac.at>, on 02/28/2013
at 06:25 PM, an...@mips.complang.tuwien.ac.at (Anton Ertl) said:

>Quadibloc <jsa...@ecn.ab.ca> writes:
>>Anyways, in a search for more information, I came to a Wikipedia page
>>with a link to a PDF of a lecture from a series about "bizarre
>>architectures", which covered the Control Data 3600 and 6600. They
>>apparently were bizarre because they had 6-bit characters instead of 8-
>>bit characters.
>>
>>I'll have to say that I found that hyperbolic.

I found it stark raving bonkers. Essentially[1] every binary computer
of that era used 6-bit characters.

>The IBM S/360 introduced byte addressing and the 8-bit byte,

No, it introduced the "any size that you want as long as it's eight"
in place of the byte addressing on the earlier 7030.

[1] The IBM 7030 (Stretch) is the only exception that comes to
mind.

[Shmuel Metz]

In <kgo1sb$onj$1...@dont-email.me>, on 02/28/2013

at 08:51 AM, Stephen Fuld <SF...@alumni.cmu.edu.invalid> said:

>I wouldn't go as far as bizarre, but it is unusual in that it is
>irregular.

The PDP-6 and PDP-10 didn't have support for bytes that straddled word
boundaries; droping one bit per word was the simplest way to handle
it.

>Was there specific hardware support for this format to make things
>easier?

There were generic byte instructions: Adjust Byte Pointer, Deposit
Byte, Increment Byte Pointer, Increment Pointer and Deposit Byte,
Increment Pointer and Load Byte, Load Byte.

[Dan Espen]

Sometime in the mid 90s I was doing tech support for a large z/OS project
written in C and mostly ported from UNIX. Almost all the developers
were refugees from UNIX.

There was lowercase almost everywhere.

The first dump I got in from field had all the function names in the
dump translated to periods (marked as unprintable characters). I had
to get the customer to change their dump options so that lower case
would get printed. Up until then there must not have been enough
lower case in dumps for anyone to care.

--
Dan Espen

[Gerard Schildberger]

On Thursday, February 28, 2013 2:26:33 PM UTC-6, Peter Flass wrote:
> On 2/28/2013 2:00 PM, Anne & Lynn Wheeler wrote:

>> nmm1 writes:
>>> So did (many? most?) of the System/360 (and System/370?) series.

>>> Rumour has it that they had to fix the architecture before IBM
>>> Galactic Headquarters took a decision to go with EBCDIC, and it
>>> never had any firmware (let alone software) written to go with
>>> it. Nobody knew what would happen if you turned it on :-)

>> recent discussion of 360 ascii in mainframe mailing list
>> http://www.garlic.com/~lynn/2013b.html#72 One reasonf or monocase was Re: Dualcase vs monocase
>> http://www.garlic.com/~lynn/2013b.html#73 One reasonf or monocase was Re: Dualcase vs monocase
>> "The Biggest Computer Goof Ever":
>> http://www.bobbemer.com/P-BIT.HTM
>> from above:
>> I mention this because it is a classic software mistake. IBM was going
>> to announce the 360 in 1964 April as an ASCII machine, but their
>> printers and punches were not ready to handle ASCII, and IBM just HAD to
>> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
>> had a store of spendable money. They put in the P-bit. Set one way, it
>> ran in EBCDIC. Set the other way, it ran in ASCII.

> I've never been clear exactly what this would have done. A character is
> just an n-bit chunk with no intrinsic interpretation. It only becomes a
> character when it is printed, or punched.

> Pete

Except when using the ED and EDMK (edit, edit with mark) instructions.
____________________________________________________ Gerard Schildberger

[Terje Mathisen]

The only reason I remembered that was because I learned to program (in
Fortran 2) on an 110x using Fielddata.

The bitness of the chars really didn't matter to me though, since the
only way I had to handle characters was as integers, and print them with
fixed-size '27Hxxxxx' format specifiers...

Not 'The Good Old Days'.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Ivan Godard]

On 2/28/2013 10:59 PM, Terje Mathisen wrote:

> The only reason I remembered that was because I learned to program (in
> Fortran 2) on an 110x using Fielddata.
>
> The bitness of the chars really didn't matter to me though, since the
> only way I had to handle characters was as integers, and print them with
> fixed-size '27Hxxxxx' format specifiers...
>
> Not 'The Good Old Days'.

Au contraise mon frere. I did the first Mary compiler on the 1108 at NTH
Regnecentralen, in Algol 60 and fielddata targeting the Kongsberg SM-4
and Nord-1. One of the happier times of my life :-)

Ivan

[Robert Wessel]

On Thu, 28 Feb 2013 18:38:40 +0000 (GMT), nm...@cam.ac.uk wrote:

>In article <HgNXs.488269$ck1.3...@fed05.iad>,
>Scott Lurndal <sl...@pacbell.net> wrote:
>>>
>>>The EBCDIC and ASCII character computers rarely needed to use other
>>>coding systems unless they were talking to a different make of computer.
>>
>>Burroughs B3500 had a processor toggle that would tell the processor to
>>interpret a byte as ASCII or EBCDIC (mainly for inserting zone digits). This
>>feature was removed from the B4900 on.
>

>So did (many? most?) of the System/360 (and System/370?) series.
>Rumour has it that they had to fix the architecture before IBM
>Galactic Headquarters took a decision to go with EBCDIC, and it
>never had any firmware (let alone software) written to go with
>it. Nobody knew what would happen if you turned it on :-)

(addressing several posts in this subthread)

S/360 had an ASCII bit, which impacted the operation of several
instructions. This was implemented on most (or all) S/360s, although
it's possible that some of the odder machines omitted it.

That mode bit was reused on S/370 to select "Extended Control" mode,
which rearranged some system level stuff and was a prerequisite to
enabled paging. So no S/370 included ASCII mode. Note that the
360/67 had a different method of enabling its equivalent of EC mode,
and it retained ASCII mode in both Basic and Extended modes.

ASCII mode only impacted a limited number of instructions, and only in
what their outputs were.

Instructions that generated packed decimal results (AP, SP, ZAP, MP,
DP, CVD) would generate the ASCII preferred sign nibbles (0x?A and
0x?B) instead of the EBCDIC ones (0x?C and 0x?D) . Note that all of
those instructions (to this day) always accept both sets of signs as
input.

Instructions that expanded packed decimal fields into character fields
(UNPK, ED, EDMK) would generate either the EBCIDIC (0xf?) or ASCII
(0x3?) high nibble as appropriate for the mode. Again, inputs were
not affected.

I'm pretty sure the sum total impact of ASCII mode was on the outputs
of those nine instructions.

Despite basically never having been used, it seems unlikely that a
mode with such minor impact wouldn't have been tested, especially as
it was documented from day one.

I/O devices were a different issue, particularly printers and punches
(disk and tape devices, for example, were mostly insensitive to the
character coding). And it may have been punch card equipment
specifically, since the way print trains were mapped on most printers
of that era (basically there was storage associating a character code
with each slug on the print train, and when the slug matching the
printed character passed the correct position the hammer was
triggered)) should have made an ASCII interpretation pretty
straight-forward, with the possible exception of folding (automatic
lower-to-uppercase conversion). But those are pretty much outside the
CPU.

But IBM never delivered any OS's using ASCII mode. In more recent
machines a number of instructions have been added to better support
ASCII, although the decimal instructions still use only the EBCDIC
"mode".

[Stephen Fuld]

On 2/28/2013 3:31 PM, Shmuel (Seymour J.) Metz wrote:
> In <YMuXs.19513$DO....@fe40.iad>, on 02/27/2013
> at 09:20 PM, sc...@slp53.sl.home (Scott Lurndal) said:
>
>> and 8 on the B3500 (medium systems) line. FWIW, B5000 is
>> considered an ancestor of the B6500
>
> FSVO ancestor.
>
>> (with the B5500 derived from the B5000 and
>> the B6500 a tredy-designed larger B5500)
>
> Not even close. The B5000, B5500 and B5700 have a common architecture;
> the B6500 is a totally new design.
>
> What was the fate of the UNIVAC 490 line?

Univac had pretty much phased them out by the mid 1970s (though a few
remained). The 1100/80 had a mode to emulate the 494, though I never
heard of anyone using it.

BTW, Univac also had the 418 series, which had 18 bit words. The only
use I know of for them was by Western Union as front ends for their
telegram systems. They were gone even before the 490s.




--
- Stephen Fuld
(e-mail address disguised to prevent spam)

[nm...@cam.ac.uk]

In article <icmwunu...@home.home>, Dan Espen <des...@verizon.net> wrote:

>hanc...@bbs.cpcn.com writes:
>
>> What was sad was that once it became easy to enter and print lower
>> case letters (via better terminals and xerographic printers in the mid
>> 1980s), many organizations didn't bother upgrading their programs, and
>> they continued to print in all caps.
>
>Sometime in the mid 90s I was doing tech support for a large z/OS project
>written in C and mostly ported from UNIX. Almost all the developers
>were refugees from UNIX.
>
>There was lowercase almost everywhere.

Unixoids have traditionaly had trouble locating the shift key :-)

>The first dump I got in from field had all the function names in the
>dump translated to periods (marked as unprintable characters). I had
>to get the customer to change their dump options so that lower case
>would get printed. Up until then there must not have been enough
>lower case in dumps for anyone to care.

Back in 1972, when we got our first System/370, one of the first
things that we specified was printer chains that supported both
cases. But Cambridge, in the 1960s, was one of the 2-3 leading
universities in the use of computers in the 'soft' sciences.
At one time in the 1970s, ancient Thibetan was the second most
common language printed on our line printers (in a transliteration
to Latin letters, of course).

So not everywhere was like that, but many IBM shops were.


Regards,
Nick Maclaren.

[nm...@cam.ac.uk]

In article <kgpkcu$9qk$1...@dont-email.me>,

Yes. Fortran was appalling for character handling before Fortran 77,
but there were a LOT of better languages.


Regards,
Nick Maclaren.

[Stephen Fuld]

On 2/28/2013 11:21 PM, Robert Wessel wrote:

snip

> I/O devices were a different issue, particularly printers and punches
> (disk and tape devices, for example, were mostly insensitive to the
> character coding).

I vaguely remember a parameter on the DD card that invoked ASCII for
tapes. IIRC, it had to do with the ability to read ANSI standard
interchange format, which had ASCII data, and had ANSI standard tape
labels, which, besides using ASCII had a slightly different format than
IBM standard labels. Whether this all did hardware translate, and if
so, where in the system the hardware was located, is lost in my memory
banks. :-(

[Robert Wessel]

OPTCD=Q on the DCB subparameter.

That was (is) strictly translated by software. Of course it was
mostly useless, since it had no way to specify what parts of the input
record were binary.

There was other oddness for 7-track tape support.

[nm...@cam.ac.uk]

In article <4sr0j8dmu781jr8ku...@4ax.com>,

And how! Not just on IBM, either - ICL short-inter-block-gap format
was a particularly delightful aberration - except to people who
wanted to read old tapes :-)

I have a program that I wrote to unpick 1/2" tapes inder Unix, and
it handles a large number of MVS formats (including pretty well all
9-track formats, IEBCOPY dumped PDSs etc.), but it would have
hysterics if I fed it a 7-track one.


Regards,
Nick Maclaren.

[Terje Mathisen]

So we used the very same 1108 then!

NTH changed name to NTNU when they merged the technical institute with
the rest of university-level colleges in Trondheim, this happened
shortly after my time.

(BTW, I have been exposed to Mary just once, in the form of an OS exam I
took after graduating, while working at SINTEF.)

[Peter Flass]

On 2/28/2013 9:36 PM, Anne & Lynn Wheeler wrote:
>
> there was actually a different kind of problem involving IBM termianls
> and ASCII terminals.
>
> IBM terminals weren't ebcdic ... and so terminal data had to be
> translated back&forth between terminal bit pattern and ebcdic bit
> pattern.

I recently re-discovered this and it surprised me - the 2741, the
premier IBM hardcopy terminal for CMS was BCD!

--
Pete

[Peter Flass]

One of the first applications I specified at the college was the
printing of financial aid award letters in mixed case, finding a real
use for out new LN03 laser printer that I had ordered because I wanted
one to play with.

--
Pete

[Peter Flass]

On 2/28/2013 9:43 PM, hanc...@bbs.cpcn.com wrote:
> On Feb 27, 4:20 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> Thereafter, the large systems designs alternated between southern cal and
>> tredyffrin Pa.
>
> I was about to ask if that arrangement wasn't very inefficient. But
> then I recalled that IBM assigned one model of System/360 to an
> English town (Helmsley?) Somewhere I read that IBM set up an overseas
> private line to interconnect its locations. Back then that was
> enormously expensive.

Maybe Hursley? I think most S/360 models were designed in different
locations - I'd have to check Pugh to verify. I know models came out of
Poughkeepsie, Endicott, Hursley, and Sindelfingen. Most of them used
entirely different technologies. Back in the days before the Internet
it must have been quite a challenge to keep everyone on the same page,
or at least in the same book.


--
Pete

[Quadibloc]

On Mar 1, 1:07 am, n...@cam.ac.uk wrote:

> At one time in the 1970s, ancient Thibetan was the second most
> common language printed on our line printers (in a transliteration
> to Latin letters, of course).

Ah, I thought you had a rather unique custom print train when I first
heard this. For that, the ALA print train would do.

John Savard

[Peter Flass]

On 2/28/2013 6:36 PM, Shmuel (Seymour J.) Metz wrote:
> In <861uc0f...@chai.my.domain>, on 02/28/2013
> at 01:19 PM, Patrick Scheible <k...@zipcon.net> said:
>
>> On the PDP-10 there are instructions to pack and unpack any length of
>> byte from words. I'm sure other word-oriented machines had them as
>> well.
>
> The VFL unit of the IBM 7030 could handle byte strings with bytes that
> crossed word boundaries; the CDC 3600 and 3800 could access single
> byte. The B1700 also had byte handling features, but I don't know the
> details. I believe that the EIS in GE HoneyBull also had limited byte
> handling capability.
>

EIS had pretty extensive byte capabilities including (IIRC) an edit-type
instruction. XDS Sigma systems did pretty well too, using byte pointers
like IBM's MVCL, etc. This was considered a requirement in those days
for any system with pretensions of "commercial" use.

--
Pete

[Quadibloc]

On Feb 28, 3:04 pm, Bill Findlay <yaldni...@blueyonder.co.uk> wrote:
> On 28/02/2013 21:26, in article 86obf4dt9s....@chai.my.domain, "Patrick
>
> Scheible" <k...@zipcon.net> wrote:
> > Tom Gardner <spamj...@blueyonder.co.uk> writes:
> >...
>
> >> Yes indeed, or maybe it is just a lack of imagination.
>
> >> I rather like machines with a 39-bit word and two instructions per word.
>
> > Are there real machines like that?  19 bits per instruction and one
> > extra bit?
>
> Yes, the Elliott 803A/B and 503.
>
> If the extra bit was set, the operand of the first instruction in the word
> acted as a modifier on the effective address of the second instruction.
>
> Elliott computers were all quite ... eccentric.

That's not too terribly crazy, though. The word length is presumably
just what was needed, not one bit more or less... and the extra bit
between two instructions lets one have more flexibility than either
indirect addressing or indexing would provide... with less hardware!

Now, I'd use the result of the first instruction, instead of having it
go to the accumulator, as an index instead. But this choice might have
let the two instructions overlap for higher speed.

John Savard