Explanation needed of binary operators

P

Patricia Shanahan

Roedy said:
ASCII has the same strangeness.
0-9 are 30-39.

I suspect the reason was pedantry. It would be even harder to get
students to understand the difference between the number 0 and the
character 0 if they had the same binary representation.

For ASCII, I think there was some deference to paper tape mechanics.
Treating no holes as NUL allows records to be separated by blocks of
unpunched tape. Treating all holes as DEL allows anything to be
overpunched into being a DEL.

Patricia
 
S

Stefan Ram

Roedy Green said:
I suspect the reason was pedantry. It would be even harder to
get students to understand the difference between the number 0
and the character 0 if they had the same binary representation.

On teletypes, one could get certain effects with the bit
patterns »NUL« (»0000000«) and »DEL« (»1111111«).

DEL will punch all-holes, so it will erase any information.

When the motor starts, the first characters sent might be
lost, so sending some NULs at the start of a transmission will
give the motor time to start.

This dictated that the blocks containing those bit patterns
had to be control blocks in X3.4-1963.

I am working on a German language page about X3.4-1963:

http://www.purl.org/stefan_ram/pub/ascii_1963_de
 
R

Roedy Green

I am working on a German language page about X3.4-1963:

Then did ASCII come out. I recall talking with Vern Detwiler (who
later founded MacDonald Detwiler) about what character set we should
use for the new IBM 7044. Back then each university devised it own
character set. I remember him talking about same new fangled 7-bit
code called ASCII. He was devising our 6-bit code to be as compatible
as possible with it.

Back then I was using 4 and 6 bit paper tape. Punch cards were mostly
1 or 2 holes of a possible 12. Later I used TTYs. I forget how many
holes wide their tape was, though I certainly remember editing
programs with paper tape, where you would copy up the error, type the
correction, manually space over the error, and resume the copy at
perhaps the blinding speed of 15 cps. It seems amazing what I was
able to accomplish with such primitive editing tools.
 
M

Martin Gregorie

Patricia said:
For ASCII, I think there was some deference to paper tape mechanics.
Treating no holes as NUL allows records to be separated by blocks of
unpunched tape. Treating all holes as DEL allows anything to be
overpunched into being a DEL.
As a long lapsed user of the Flexowriter and the ASR-33 teletype, not to
mention the manual 8 hole paper tape punch this is exactly right.


FWIW my original wonderment at non use of 00-09 was because AFAICR
everybody and everything except IBM's EBCDIC sorts numerics before
alphabetics and, unless I've confused what little history I ever knew,
always has done it that way since Adam were a lad.

Given that EBCDIC puts capitals in zones 1-3 and lower case in zones
4-6, the only sensible place to put numerics is zone 0 because that
would preserve a natural sort order. I don't agree that this would cause
confusion over 00. A completely blank card column meant 'space' and a
zero was a single hole punched in the zero row.
 
M

Martin Gregorie

Roedy said:
Back then I was using 4 and 6 bit paper tape. Punch cards were mostly
1 or 2 holes of a possible 12. Later I used TTYs. I forget how many
holes wide their tape was, though I certainly remember editing
programs with paper tape, where you would copy up the error, type the
correction, manually space over the error, and resume the copy at
perhaps the blinding speed of 15 cps. It seems amazing what I was
able to accomplish with such primitive editing tools.
I always liked paper tape. It was less bulky than cards and you didn't
need to find a card sorter or spend hours rebuilding the deck if you
dropped it. Tangles? Just throw the tape out a top floor window or down
the stair well (remembering to keep a grip on one end) and rewind it.

The only advantages of cards were that they were great for shopping
lists and you could make a neat glider from two cards and a pencil.
 
M

Mike Schilling

Martin said:
I always liked paper tape. It was less bulky than cards and you didn't
need to find a card sorter or spend hours rebuilding the deck if you
dropped it. Tangles? Just throw the tape out a top floor window or
down the stair well (remembering to keep a grip on one end) and
rewind it.
The only advantages of cards were that they were great for shopping
lists and you could make a neat glider from two cards and a pencil.

If you throw a card deck from a high window, it becomes nice (if oversized)
confetti.
 
P

Patricia Shanahan

Martin said:
I always liked paper tape. It was less bulky than cards and you didn't
need to find a card sorter or spend hours rebuilding the deck if you
dropped it. Tangles? Just throw the tape out a top floor window or down
the stair well (remembering to keep a grip on one end) and rewind it.

The only advantages of cards were that they were great for shopping
lists and you could make a neat glider from two cards and a pencil.

There were some other advantages:

1. Content printing on each card. I could never, even when I was
handling paper tape a lot, read ASCII codes as fast as I could read
printed text.

2. Ease of changes in the middle of a file. The two procedures for tape
were the one Roedy described above, and physical cut-and-splice.
Splicing increased the risk of mechanical problems. Contrast that with
inserting and removing cards in the middle of a card deck.

Patricia
 
M

Martin Gregorie

Mike said:
If you throw a card deck from a high window, it becomes nice (if oversized)
confetti.
Quite.

And the sorter was no use unless you put sequence numbers on the deck and
maintained it as well. That's why the original COBOL spec had a 6 digit
sequence number at the start of every line.
 
M

Martin Gregorie

I forgot a third: the chads made great, if itchy confetti.

And a fourth: card correction by pushing chad(s) into holes before
punching new ones with a 12 key hand punch. This only worked if, like
us, you used optical card readers that didn't flex the cards.
There were some other advantages:

1. Content printing on each card. I could never, even when I was
handling paper tape a lot, read ASCII codes as fast as I could read
printed text.
I used to be able to read enough (newline, tab, space, numbers) to find
the right place on a tape.

As regards cards: our programmer's standby, the 12 key hand punch,
didn't print, so I learnt to read card codes at a good rate. Later we
were given printing hand punches but they were like a Dymo tape punch:
you had to dial the character and then hit to PUNCH bar to punch a
column. They were slow as hell: we hated them and used the old 12 key
punches by preference. I wish I'd had the sense to liberate one of the
12 key punches when they were phased out. They were marvelous Victorian
engineering: the best ones had cast iron bodies with a riveted-on brass
name plate saying "British Tabulating Machine Company". Their punches
never got blunt or jammed and they never wore out.
2. Ease of changes in the middle of a file. The two procedures for tape
were the one Roedy described above, and physical cut-and-splice.
Splicing increased the risk of mechanical problems.
>
Not if done right. I only used tape in anger at University to write
Algol 60 for an Elliott 503, the only machine I know that was faster at
floating point than integer arithmetic. Very appropriate seeing that it
was a scientific machine. But I digress....

We used to leave a foot or so of runout between procedure declarations
and in other suitable places, so we never had to copy & edit more than a
few feet of tape and splices never overlapped punched tape. IIRC we used
thin plastic heat-seal splicing tape. I don't remember having failed
splices or tape wrecks due to splices.
Contrast that with
inserting and removing cards in the middle of a card deck.
Actually, we only used a large program pack once and then slung them
because, even in 1968, we kept all program source on tape. Once a source
had been loaded we used small decks to edit the source on tape. The
programmer's overnight run started with a batch edit run that did
everybody's edits. This was followed by a batch compile. After that
individual test shots were run from the tape holding the compiled
programs. That was on an ICL 1900. By 1970 we'd moved our sources to
disk and the card decks had become individual edit/compile/test jobs for
George 1. A typical job pack would be no more than 50-100 cards. You
kept and reshuffled the commands, replacing the edits and test data as
needed.

I may be misremembering, but I have the impression that IBM mainframe
shops retained source as card decks a lot longer than we did. Certainly,
when I did a job in an IBM System/3 shop in NYC in 1976 all program
sources and, indeed, the master files as well were still on cards: those
nasty little 96 column jobbies.

Eee, lad. Tell that to the young people of today and they'll not believe
you.
 
R

Roedy Green

I may be misremembering, but I have the impression that IBM mainframe
shops retained source as card decks a lot longer than we did

Univac required mainframes to be sold with a card reader at least as
late as 1976. Card readers were perfected shortly after they went
obsolete. Air fanned the cards and sucked the top card off the deck.
Early ones used a knife edge picker that shredded any card with an
tiny burr to the edge. You had to keep reproducing entire decks to
keep the edges clean.
 
R

Roedy Green

2. Ease of changes in the middle of a file. The two procedures for tape
were the one Roedy described above, and physical cut-and-splice.
Splicing increased the risk of mechanical problems. Contrast that with
inserting and removing cards in the middle of a card deck.

The old mechanical equipment was much more impressive than today's
pizza boxes. An optical paper tape reader shot tape out so fast it
formed a 12 foot stream in the air. A 300 LPM printer thundered with
the majesty of a Robocop. I was shocked, never having seen printing
faster than about 45 CPS before. Unit record equipment made all
manner of whirring and kachunking noises that would shake the
building. I remember writing a device drive for a Univac OCR device.
You had X milliseconds to decide what to do with the document after
you read it, which pocket to direct it to. It was a strange thing made
of rubber belts. On a 16K machine we did multithread lookahead i/o --
something modern Java programs still do NOT do.
 
M

Martin Gregorie

Roedy said:
The old mechanical equipment was much more impressive than today's
pizza boxes. An optical paper tape reader shot tape out so fast it
formed a 12 foot stream in the air.
>
Yep. ICL used Elliott 1200 cps paper tape readers, so it moved at 120
ins/sec. Big arcs of tape. The most impressive jam I ever saw was when
a bit of sticky tape got left on the end of a reel, which caught on the
drive roller. The reader pulled tape out of the bin at 120 ins.sec until
the space between roller and its guard was jammed solid and the reader
stalled. Even the engineers were impressed - and took forever to clear
the reader.
A 300 LPM printer thundered with
the majesty of a Robocop. I was shocked, never having seen printing
faster than about 45 CPS before.
>
We had a 1250 lpm drum printer. It was generally noisy but when you
printed a line of asterisks it made the most godawful KLANG as all 132
print hammers hit the drum simultaneously. It was a sufficiently fast
printer to need a power stacker which pulled in the paper to stack it:
the machine could page throw at about 3 feet a second and the stacker
had to keep up.
 
J

John W. Kennedy

Martin said:
And no,
I have no idea why 0-9 are F0-F9 rather than 00-09.

To match the existing collating sequences. (Many pre-360 machines
implemented, in their hardware, collating sequences that did not
correspond to the binary values of their character encodings; EBCDIC was
designed so that the 360 would not have that anomaly.)
 
J

John W. Kennedy

Roedy said:
ASCII has the same strangeness.
0-9 are 30-39.

I suspect the reason was pedantry. It would be even harder to get
students to understand the difference between the number 0 and the
character 0 if they had the same binary representation.

ASCII was designed more for telegraphy and interchange media than for
internal use.
 
J

John W. Kennedy

Martin said:
FWIW my original wonderment at non use of 00-09 was because AFAICR
everybody and everything except IBM's EBCDIC sorts numerics before
alphabetics and, unless I've confused what little history I ever knew,
always has done it that way since Adam were a lad.

No, IBM equipment generally collated numerics after alphabetics long
before EBCDIC, even on machines, such as the 1401, where the binary
representation was the other way. EBCDIC was designed specifically so as
to continue this behavior.

There are many ways of collating. For one dramatic example, US telephone
directories traditionally collate space after alphanumerics, so that AAA
comes before AA.
 
M

Mike Schilling

John said:
ASCII was designed more for telegraphy and interchange media than for
internal use.

You mean it was invented for one purpose, pressed into use for another, and
is still being used for the one it's not well suited for, long after the one
it was designed for has more or less disappeared? Geez, how often does that
happen? :)
 
L

Lew

Mike said:
You mean it was invented for one purpose, pressed into use for another, and
is still being used for the one it's not well suited for, long after the one
it was designed for has more or less disappeared? Geez, how often does that
happen? :)

Set to music, it's a vital tool for corporate advancement:

You gotta do some ASCII sing.
 
R

Roedy Green

We had a 1250 lpm drum printer. It was generally noisy but when you
printed a line of asterisks it made the most godawful KLANG as all 132
print hammers hit the drum simultaneously. It was a sufficiently fast
printer to need a power stacker which pulled in the paper to stack it:
the machine could page throw at about 3 feet a second and the stacker
had to keep up.

I presume you were an "operator" at some point in your career and had
a faulty mylar tape loop that controlled the vertical tab stops on the
printer, causing the paper to slew endlessly at full rate. If it
happened when the covers were up you had an great arc in the air. If
closed, it packed the printer cover tight as a mummy case. To stop it
you stomped your foot on the input paper box to break the paper.
 
R

Roedy Green

To match the existing collating sequences. (Many pre-360 machines
implemented, in their hardware, collating sequences that did not
correspond to the binary values of their character encodings; EBCDIC was
designed so that the 360 would not have that anomaly.)

I don't follow. EBCDC '0' is not binary 0. Further , IIRC, the
letters A-Z and a-z are not contiguous blocks of binary assignments.
 
M

Martin Gregorie

John said:
No, IBM equipment generally collated numerics after alphabetics long
before EBCDIC, even on machines, such as the 1401, where the binary
representation was the other way. EBCDIC was designed specifically so as
to continue this behavior.
Thanks for that correction. I came in via ICL kit in the late 60s, when
S/360 had largely replaced the 1400, so I never understood EBCDIC until
the ICL 2900 (which used EBCDIC) replaced the 1900 around 1980. ICL 1900
mainframes used the 6 bit ISO alternate character set. This sorted in
the order space, numeric, alphabetic.
There are many ways of collating. For one dramatic example, US telephone
directories traditionally collate space after alphanumerics, so that AAA
comes before AA.
>
6 bit ISO, as the 1900 used it, had two shifts (IIRC you used the SI and
SO characters to switch between them), so a sort had to really jump
through hoops if you were using mixed case keys and mixed case lookups
were a real horror which, thankfully, I managed to avoid.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top