🚀 go-pugleaf

>From article <1990Jan22.152652.7636@virtech.uucp>,
by jje@virtech.uucp (Jeremy J. Epstein):
> 
> Also, on IBM 360s (and hence on all 370 architecture systems) the
> op code for multiply was 5C, which was also the EBCDIC for '*'.
> Does anyone know if that was accidental, or coincidence?  Do other
> machines have neat opcodes like that?
>
Many of the early decimal machines had machine languages designed
this way.  Typically, these machines had a 6 bit byte addressable
memory, and stored one decimal digit per byte for arithmetic purposes.
Text was stored in something like a 6 bit BCD code, and it was common
for machine designers to make sure that the opcode for add was A, for
subtract S, for multiply M and for divide D.  Other instructions had
less convenient mnemonic opcodes, but all had some vague mnemonic value.
This was important because these machines were developed at about the
same time that various early efforts at automatic assembly were
being pursued, and the hardware designers didn't do their design
work under the assumption that assemblers (or higher level languages of
any kind) would be used.
					Doug Jones

In article <1990Jan22.152652.7636@virtech.uucp> jje@virtech.uucp (Jeremy J. Epstein) writes:
>Back in the bad old days, I keypunched all my programs on IBM 026
>card punches.  [The first time I saw an 029 I was overwhelmed with
>how modern it was]

>Does anyone out there remember the multi-punch sequences for the
>characters which weren't on the keyboard (no cheating by looking at
>old card decks)?  I think that "+" was 12-6-8, but I'm not sure.  I don't
>even remember what characters had to be multipunched besides +, (, )

**SHUDDER**  We had mostly 029's, but a few 026's, which most people avoided.
In order to minimize my waiting time I'd use them interchangably, 
multipunching EBCDIC codes on the 026.

Except for the missing keys, I actually *liked* the 026 better than the 029 --
those sleek rounded curves were ahead of their time, compared to the boxy
stying of the 029. The 026's keyboard was also detatched and could be oriented
much more to my liking than the semi-rigid keyboard of the 029.

I suppose the most remembered multipunch is 0-8-2, which was non-printing,
used all over the place, and even the 029 couldn't generate it directly.

>Also, on IBM 360s (and hence on all 370 architecture systems) the
>op code for multiply was 5C, which was also the EBCDIC for '*'.
>Does anyone know if that was accidental, or coincidence?  

Darn, you made me have to blow the dust off my manuals. It looks like a
coincidence since + - and / don't map.

>It sure helped in debugging
>programs 'cause you could look in the ASCII dump for your multiply
					^^^

actually, you would be better off looking in an EBCDIC dump!

Tom Almy
to...@tekgvs.labs.tek.com
Standard Disclaimers Apply

	I've heard that the '026 punch needed high currents and
the available relay logic couldn't handle it, so they used an
innovative no-moving-parts replacement.  They drove the punches
with vacuum tubes.  I can't be sure of the reason, but they DID
have some glowing glass thingabobs in 'em.

I am known for my brilliance,              John Whitmore
 by those who do not know me well.

In article <67...@tekgvs.LABS.TEK.COM> to...@tekgvs.LABS.TEK.COM (Tom Almy) writes:
}In article <1990Jan22.152652.7636@virtech.uucp> jje@virtech.uucp (Jeremy J. Epstein) writes:
}>Also, on IBM 360s (and hence on all 370 architecture systems) the
}>op code for multiply was 5C, which was also the EBCDIC for '*'. ...

}>It sure helped in debugging
}>programs 'cause you could look in the ASCII dump for your multiply
}					^^^
}
}actually, you would be better off looking in an EBCDIC dump!

Actually, you'd both be better off looking in a hex dump.  Is there any
other kind? (-:

I remember the first (and last) time I requested a full diagnostic dump of
one of my 370 assembler class programs, just to see what would happen.  A
two inch stack of paper and it blew my DP lab budget (had to buy more).
Ouch! (-:

-- 
The Polymath (aka: Jerry Hollombe, holl...@ttidca.tti.com)  Illegitimis non
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 450-9111, x2483
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe

In article <1990Jan22.152652.7636@virtech.uucp>, jje@virtech.uucp
(Jeremy J. Epstein) writes:

> [... about BCD overpunching on 026's...]

	The most useful BCD overpunch was record mark, 0-2-8.
	A single 1401 MCM instruction could move a variable
	length data record, terminated by a record mark.  This
	was essentially a hard-wired strcpy(), and was used
	heavily on card-to-tape and tape-to-print utility operations.

	A little-known feature of some early 709/7090 FORTRAN II
	compilers was that they recognized record marks to allow
	multiple statements per card.  For example, if "#" represents
	a record mark, they'd accept "I=0 # J=1 # K=2" on a single
	card.

> Does anyone out there remember the multi-punch sequences for the
> characters which weren't on the keyboard (no cheating by looking at
> old card decks)?  I think that "+" was 12-6-8, but I'm not sure.  I don't
> even remember what characters had to be multipunched besides +, (, )

	Actually + by itself was just a 12 punch.  Among the zone
	punches, + (12-zone) and - (11-zone) would be used in data
	for 1401 programs by overpunching the sign on the least
	significant digit of a number.  These were read in as the
	A and B bits that the 1401's hardware interpreted as
	a number's sign.

	   Related trivia:  The sign was over the least significant
	   (rightmost) digit because that's what would be addressed
	   in a 1401 instruction.  Something like an add would:

		--  Load the given addresses into the A & B address
			registers
		--  Fetch 1st byte of each, including sign
		--  For each byte until reaching one with a WM
			(word mark) bit set, add "*A" to "*B",
			then DECREMENT both address registers.

		i.e., it worked right-to-left, from the high-addressed
		end of a number toward the low-addressed end.  Number
		size was limited only by how much memory was available.

		This also allowed instructions to "chain" addresses,
		using the previous instruction's last A/B address register
		contents to define the next operand address.  A
		C-like equivaent would be something like this:

		    b[0] = a[0] + b[0]
		    +			/*  Adds a[1] to b[1]	*/
		    +			/*  Adds a[2] to b[2]	*/
		    +			/*  ... etc.		*/


----------------
Paul Raveling
Rave...@isi.edu