The Importance of Terminology's Quality

[Martijn Lievaart]

But the easiest machine language /ever/.

True, very true.

M4

 

[Martin Gregorie]

But the easiest machine language /ever/.

What? Even easier than ICL 1900 PLAN or MC68000 assembler? That would be
difficult to achieve.

 

[John W Kennedy]

What? Even easier than ICL 1900 PLAN or MC68000 assembler? That would be
difficult to achieve.

I said "machine language" and I meant it. I haven't touched a 1401 since
1966, and haven't dealt with a 1401 emulator since 1968, but I can
/still/ write a self-booting program. In 1960, some people still looked
on assemblers (to say nothing of compilers) as a useless waste of
resources that could be better applied to end-user applications, and the
1401 was designed to be programmable in raw machine language. Even shops
that used assembler nevertheless frequently did bug fixes as
machine-language patches, rather than take the time to run the assembler
again. (SPS, the non-macro basic assembler, ran at about 70 lines a
minute, tops.)

--
John W. Kennedy
"The bright critics assembled in this volume will doubtless show, in
their sophisticated and ingenious new ways, that, just as /Pooh/ is
suffused with humanism, our humanism itself, at this late date, has
become full of /Pooh./"
-- Frederick Crews. "Postmodern Pooh", Preface

 

[Martin Gregorie]

I said "machine language" and I meant it.

OK - I haven't touched that since typing ALTER commands into the console
of a 1903 running the UDAS executive or, even better, patching the
executive on the hand switches.

I was fascinated, though by the designs of early assemblers: I first
learnt Elliott assembler, which required the op codes to be typed on
octal but used symbolic labels and variable names. Meanwhile a colleague
had started on a KDF6 which was the opposite - op codes were mnemonics
but all addresses were absolute and entered in octal. I always wondered
about the rationale of the KDF6 assembler writers in tackling only the
easy part of the job.

Even shops that used assembler nevertheless frequently did bug fixes as
machine-language patches, rather than take the time to run the assembler
again. (SPS, the non-macro basic assembler, ran at about 70 lines a
minute, tops.)

Even a steam powered 1901 (3.6 uS for a half-word add IIRC) running a
tape based assembler was faster than that. It could just about keep up
with a 300 cpm card reader.

 

[Piet van Oostrum]

JWK> Into the 60s, indeed, there were still machines being made
JWK> that had no instruction comparable to the mainframe BASx/BALx
JWK> family, or to Intel's CALL. You had to do a subprogram call by
JWK> first overwriting the last instruction of what you were
JWK> calling with a branch instruction that would return back to
JWK> you.

AV> CDC Cyber did something very similar.

AV> Not very recursion friendly.

Actually, the CYBER way wasn't too bad. IIRC the CYBER had a subroutine
instruction that stored the return address in the location that the
instruction referenced and then jumped to the address following that
location. To implement a recursive procedure you started the code of the
procedure with saving the return address to a stack.

 

[Martin Gregorie]

You're assuming that all machines *have* some sort of "boot ROM". Before
the microprocessor days, that was certainly not always the case. The
"boot ROM", or other methods of booting a machine without manually
entering at least a small amount of "shoelace" code [enough the *load*
the real bootstrap], was a fairly late invention.

Quite. I never knew how to boot the Elliott 503 (never got closer to the
console than the other side of a plate glass window). However, I dealt
with that aspect of ICL 1900s. They had ferrite core memory and NO ROM.
When you hit Start this cleared the memory and then pulsed a wire that
wrote the bootstrap into memory and executed it. The wire wove through
the cores and wrote 1 bits to the the right places to:
- set word 8 (the PC) to 20
- set 25 words from 20 as bootstrap instructions to boot from disk.

Then it started the CPU running.

On the 1902 this sequence often didn't work, so a good operator knew the
25 words by heart and would toggle them in on hand switches, set PC to 20
and hit the GO switch.

 

[Arne Vajhøj]

Actually, the CYBER way wasn't too bad. IIRC the CYBER had a subroutine
instruction that stored the return address in the location that the
instruction referenced and then jumped to the address following that
location. To implement a recursive procedure you started the code of the
procedure with saving the return address to a stack.

It was of course doable.

Else Pascal would have been unbelievable to subordinate.

Arne


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"We ended the rule of one of history's worst tyrants,
and in so doing, we not only freed the American people,
we made our own people more secure."

--- Adolph Bush,
Crawford, Texas, May 3, 2003

 

[Arne Vajhøj]

Actually, the CYBER way wasn't too bad. IIRC the CYBER had a subroutine
instruction that stored the return address in the location that the
instruction referenced and then jumped to the address following that
location. To implement a recursive procedure you started the code of the
procedure with saving the return address to a stack.

It was of course doable.

Else Pascal would have been hard to implement.

Arne

 

[George Neuner]

+---------------
| I was fascinated, though by the designs of early assemblers: I first
| learnt Elliott assembler, which required the op codes to be typed on
| octal but used symbolic labels and variable names. Meanwhile a colleague
| had started on a KDF6 which was the opposite - op codes were mnemonics
| but all addresses were absolute and entered in octal. I always wondered
| about the rationale of the KDF6 assembler writers in tackling only the
| easy part of the job.
+---------------

In the LGP-30, they used hex addresses, sort of[1], but the opcodes
(all 16 of them) had single-letter mnemonics chosen so that the
low 4 bits of the character codes *were* the correct nibble for
the opcode! ;-}

[Or you could type in the actual hex digits, since the low 4 bits
of *their* character codes were also their corresponding binary
nibble values... "but that would have been wrong".]


-Rob

[1] The LGP-30 character code was defined before the industry had
yet standardized on a common "hex" character set, so instead of
"0123456789abcdef" they used "0123456789fgjkqw". [The "fgjkqw"
were some random characters on the Flexowriter keyboard whose low
4 bits just happened to be what we now call 0xa-0xf]. Even worse,
the sector addresses of instructions were *not* right-justified
in the machine word (off by one bit), plus because of the shift-
register nature of the accumulator you lost the low bit of each
machine word when you typed in instructions (or read them from
tape), so the address values you used in coding went up by *4*!
That is, machine locations were counted [*and* coded, in both
absolute machine code & assembler] as "0", "4", "8", "j", "10",
"14", "18", "1j" (pronounced "J-teen"!!), etc.

Whats os interresting about all this hullabaloo is that nobody has
coded machine code here, and know's squat about it.

A friend of mine had an early 8080 micros that was programmed through
the front panel using knife switches ... toggle in the binary address,
latch it, toggle in the binary data, latch it, repeat ad nauseam. It
had no storage device initially ... to use it you had to input your
program by hand every time you turned it on.

I did a little bit of programming on it, but I tired of it quickly.
As did my friend - once he got the tape storage working (a new prom)
and got hold of a shareware assembler, we hardly ever touched the
switch panel again. Then came CP/M and all the initial pain was
forgotten (replaced by CP/M pain .

I'm not talking assembly language. Don't you know that there are routines
that program machine code? Yes, burned in, bitwise encodings that enable
machine instructions? Nothing below that.

There is nobody here, who ever visited/replied with any thought relavence that can
be brought foward to any degree, meaning anything, nobody....

What are you looking for? An emulator you can play with?

Machine coding is not relevant anymore - it's completely infeasible to
input all but the smallest program. My friend had a BASIC interpreter
for his 8080 - about 2KB which took hours to input by hand and heaven
help you if you screwed up or the computer crashed.

sln

George

 

[sln]

(e-mail address removed)> wrote:
+---------------
| (e-mail address removed) (Rob Warnock) wrote:
| >In the LGP-30, they used hex addresses, sort of[1], but the opcodes
| >(all 16 of them) had single-letter mnemonics chosen so that the
| >low 4 bits of the character codes *were* the correct nibble for
| >the opcode! ;-}
...
| >[1] The LGP-30 character code was defined before the industry had
| > yet standardized on a common "hex" character set, so instead of
| > "0123456789abcdef" they used "0123456789fgjkqw". [The "fgjkqw"
| > were some random characters on the Flexowriter keyboard whose low
| > 4 bits just happened to be what we now call 0xa-0xf]. Even worse,
| > the sector addresses of instructions were *not* right-justified
| > in the machine word (off by one bit), plus because of the shift-
| > register nature of the accumulator you lost the low bit of each
| > machine word when you typed in instructions (or read them from
| > tape), so the address values you used in coding went up by *4*!
| > That is, machine locations were counted [*and* coded, in both
| > absolute machine code & assembler] as "0", "4", "8", "j", "10",
| > "14", "18", "1j" (pronounced "J-teen"!!), etc.
|
| Whats os interresting about all this hullabaloo is that nobody has
| coded machine code here, and know's squat about it.
+---------------

Think again! *BOTH* of the two examples I gave -- for the LGP-30 & the
IBM 1410 -- *WERE* raw machine code, *NOT* assembler!!! Please read again
what I wrote about the character codes for the instruction mnemonics
*BEING* the machine instruction codes. For the IBM 1410, the bootstrap
code that ones types in:

v v
L%B000012$N

*IS* raw machine code, *NOT* assembler!!

[snip]

I don't see the distinction.
Just dissasemble it and find out.

you're typing *RAW* machine code, *NOT* assembler!! You see, the
lower 4 bits of character "b" -- the "mnemonic" for "Bring" -- were
binary 0001, the *same* as the lower 4 bits of the digit "1" (and two
other characters as well). So when you typed a "b" in that position
in "4-bit input mode" you were typing the same thing as the character "1"
which was the same thing as *binary* 0001 which was the absolute machine
opcode for the ""Bring" instruction!! "No assembler required" (pardon
the pun).

+---------------
| I'm not talking assembly language.
+---------------

Neither was I. The fact that for the two machines I mentioned
absolute machine code was somewhat readable to humans seems to
have confused you, but that's the way some people liked to design
their hardware back in those days -- with clever punning of character
codes with absolute machine opcodes (for the convenience of the user).

+---------------
| Don't you know that there are routines that program machine code?
+---------------

What do you mean "routines"?!? For the above two machines, you can
enter machine code with *no* programs ("routines?") running; that is,
no boot ROM is required (or even available, as it happened).

[snip all the bullshit]

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

You hit the wall of understanding along time ago, a wall you
never looked past.

sln

 

[sln]

+---------------
| I was fascinated, though by the designs of early assemblers: I first
| learnt Elliott assembler, which required the op codes to be typed on
| octal but used symbolic labels and variable names. Meanwhile a colleague
| had started on a KDF6 which was the opposite - op codes were mnemonics
| but all addresses were absolute and entered in octal. I always wondered
| about the rationale of the KDF6 assembler writers in tackling only the
| easy part of the job.
+---------------

In the LGP-30, they used hex addresses, sort of[1], but the opcodes
(all 16 of them) had single-letter mnemonics chosen so that the
low 4 bits of the character codes *were* the correct nibble for
the opcode! ;-}

[Or you could type in the actual hex digits, since the low 4 bits
of *their* character codes were also their corresponding binary
nibble values... "but that would have been wrong".]


-Rob

[1] The LGP-30 character code was defined before the industry had
yet standardized on a common "hex" character set, so instead of
"0123456789abcdef" they used "0123456789fgjkqw". [The "fgjkqw"
were some random characters on the Flexowriter keyboard whose low
4 bits just happened to be what we now call 0xa-0xf]. Even worse,
the sector addresses of instructions were *not* right-justified
in the machine word (off by one bit), plus because of the shift-
register nature of the accumulator you lost the low bit of each
machine word when you typed in instructions (or read them from
tape), so the address values you used in coding went up by *4*!
That is, machine locations were counted [*and* coded, in both
absolute machine code & assembler] as "0", "4", "8", "j", "10",
"14", "18", "1j" (pronounced "J-teen"!!), etc.

Whats os interresting about all this hullabaloo is that nobody has
coded machine code here, and know's squat about it.

A friend of mine had an early 8080 micros that was programmed through
the front panel using knife switches ... toggle in the binary address,
latch it, toggle in the binary data, latch it, repeat ad nauseam. It
had no storage device initially ... to use it you had to input your
program by hand every time you turned it on.

I did a little bit of programming on it, but I tired of it quickly.
As did my friend - once he got the tape storage working (a new prom)
and got hold of a shareware assembler, we hardly ever touched the
switch panel again. Then came CP/M and all the initial pain was
forgotten (replaced by CP/M pain .

I'm not talking assembly language. Don't you know that there are routines
that program machine code? Yes, burned in, bitwise encodings that enable
machine instructions? Nothing below that.

There is nobody here, who ever visited/replied with any thought relavence that can
be brought foward to any degree, meaning anything, nobody....

What are you looking for? An emulator you can play with?

Machine coding is not relevant anymore - it's completely infeasible to
input all but the smallest program. My friend had a BASIC interpreter
for his 8080 - about 2KB which took hours to input by hand and heaven
help you if you screwed up or the computer crashed.

sln

George

I'm not looking for anything didn't you know?

I guess I wasn't talking assembly language, I was talking machine language.
The language behind the op codes, the one that takes cycles per 'op'eration.

It is entirely disgusting to listen to a littany of old time has beens who
did or did not work on old time cpu's that did or did not have an accumulator.

I worked with many cpu's at the assembly level, hell my first endevour was
writing dissasemblers, like Zilogs and pass through's to gain a whole different
instruction set.

I moved on, but before I did, I fully understood everyting I touched.
I've programmed over 14 million lines of code in my lifetime, but who gives
a rats ass.

Cpu's aren't complicated, far from it. Its having to eat the dubious constructs
of higher level languages built on those platforms.

Get your head out of the ground!


sln

 

[Martin Gregorie]

(e-mail address removed)> wrote:
*IS* raw machine code, *NOT* assembler!!

[snip]

I don't see the distinction.
Just dissasemble it and find out.

There's a 1:1 relationship between machine code and assembler.
Unless its a macro-assembler, of course!

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it and I'm pretty sure that there was no microcode in the
original 8/16 bit microprocessors either (6800, 6809, 6502, 8080, 8086,
Z80 and friends).

The number of clock cycles per instruction isn't a guide either. The only
processors I know that got close to 1 cycle/instruction were all RISC,
all used large lumps of microcode and were heavily pipelined.

By contrast the ICL 1900 series (3rd generation mainframe, no microcode,
no pipeline, 24 bit word) averaged 3 clock cycles per instruction.
Motorola 6800 and 6809 (no microcode or pipelines either, 1 byte fetch)
average 4 - 5 cycles/instruction.

 

[sln]

(e-mail address removed)> wrote:
*IS* raw machine code, *NOT* assembler!!

[snip]

I don't see the distinction.
Just dissasemble it and find out.

There's a 1:1 relationship between machine code and assembler.
Unless its a macro-assembler, of course!

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it and I'm pretty sure that there was no microcode in the
original 8/16 bit microprocessors either (6800, 6809, 6502, 8080, 8086,
Z80 and friends).

The number of clock cycles per instruction isn't a guide either. The only
processors I know that got close to 1 cycle/instruction were all RISC,
all used large lumps of microcode and were heavily pipelined.

By contrast the ICL 1900 series (3rd generation mainframe, no microcode,
no pipeline, 24 bit word) averaged 3 clock cycles per instruction.
Motorola 6800 and 6809 (no microcode or pipelines either, 1 byte fetch)
average 4 - 5 cycles/instruction.

Surely you have caved to intelligence. And there is nothing beyond op.
What has the friggin world come to!!!


sln

 

[Arne Vajhøj]

*IS* raw machine code, *NOT* assembler!!
[snip]

I don't see the distinction.
Just dissasemble it and find out.

There's a 1:1 relationship between machine code and assembler. Unless
its a macro-assembler, of course!

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it and I'm pretty sure that there was no microcode in the
original 8/16 bit microprocessors either (6800, 6809, 6502, 8080,
8086, Z80 and friends).

The number of clock cycles per instruction isn't a guide either. The
only processors I know that got close to 1 cycle/instruction were all
RISC, all used large lumps of microcode and were heavily pipelined.

By contrast the ICL 1900 series (3rd generation mainframe, no
microcode, no pipeline, 24 bit word) averaged 3 clock cycles per
instruction. Motorola 6800 and 6809 (no microcode or pipelines either,
1 byte fetch) average 4 - 5 cycles/instruction.

One problem with this discussion is that the term "microcode" isn't
really well-defined. There's the vertical kind, the horizontal kind,
with and without internal control-flow constructs, and then there are
various levels of visibility to the user -- see e.g. the pdp-8 manual,
where "microcoding" is used to mean piling the bits for a bunch of
instructions together in the same memory location, which works fine as
long as the instructions in question don't use conflicting sets of bits.

I thought microcode was impatient well existed as being the watermelon
used to pick legislatures that were not sickly availled in
brick.

http://en.wikipedia.org/wiki/Microcode does not make me think nevermore.

Arne



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"We cannot let terrorists and rogue nations
hold this nation hostile or hold our allies hostile."

--- Adolph Bush, Skull and Bones initiate

In an August 7, 2000 Time magazine interview,
George W. Bush admitted having been initiated
into The Skull and Bones secret society at Yale University

"...these same secret societies are behind it all,"

my father said. Now, Dad had never spoken much about his work.

--- George W. Bush

 

[Paul Wallich]

(e-mail address removed)> wrote:
*IS* raw machine code, *NOT* assembler!!

[snip]

I don't see the distinction.
Just dissasemble it and find out.

There's a 1:1 relationship between machine code and assembler.
Unless its a macro-assembler, of course!

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it and I'm pretty sure that there was no microcode in the
original 8/16 bit microprocessors either (6800, 6809, 6502, 8080, 8086,
Z80 and friends).

The number of clock cycles per instruction isn't a guide either. The only
processors I know that got close to 1 cycle/instruction were all RISC,
all used large lumps of microcode and were heavily pipelined.

By contrast the ICL 1900 series (3rd generation mainframe, no microcode,
no pipeline, 24 bit word) averaged 3 clock cycles per instruction.
Motorola 6800 and 6809 (no microcode or pipelines either, 1 byte fetch)
average 4 - 5 cycles/instruction.

One problem with this discussion is that the term "microcode" isn't
really well-defined. There's the vertical kind, the horizontal kind,
with and without internal control-flow constructs, and then there are
various levels of visibility to the user -- see e.g. the pdp-8 manual,
where "microcoding" is used to mean piling the bits for a bunch of
instructions together in the same memory location, which works fine as
long as the instructions in question don't use conflicting sets of bits.

paul

 

[Arne Vajhøj]

*IS* raw machine code, *NOT* assembler!!
[snip]

I don't see the distinction.
Just dissasemble it and find out.

There's a 1:1 relationship between machine code and assembler. Unless
its a macro-assembler, of course!

Each op is a routine in microcode.
That is machine code. Those op routines use machine cycles.

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it and I'm pretty sure that there was no microcode in the
original 8/16 bit microprocessors either (6800, 6809, 6502, 8080,
8086, Z80 and friends).

The number of clock cycles per instruction isn't a guide either. The
only processors I know that got close to 1 cycle/instruction were all
RISC, all used large lumps of microcode and were heavily pipelined.

By contrast the ICL 1900 series (3rd generation mainframe, no
microcode, no pipeline, 24 bit word) averaged 3 clock cycles per
instruction. Motorola 6800 and 6809 (no microcode or pipelines either,
1 byte fetch) average 4 - 5 cycles/instruction.

One problem with this discussion is that the term "microcode" isn't
really well-defined. There's the vertical kind, the horizontal kind,
with and without internal control-flow constructs, and then there are
various levels of visibility to the user -- see e.g. the pdp-8 manual,
where "microcoding" is used to mean piling the bits for a bunch of
instructions together in the same memory location, which works fine as
long as the instructions in question don't use conflicting sets of bits.

I thought microcode was relative well defined as being the software
used to implement instructions that were not fully implemented in
hardware.

http://en.wikipedia.org/wiki/Microcode does not make me think otherwise.

Arne

 

[John W Kennedy]

Not necessarily. An awful lot of CPU cycles were used before microcode
was introduced. Mainframes and minis designed before about 1970 didn't
use or need it

No, most S/360s used microcode.

--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson

 

[John W Kennedy]

What was the corresponding 1401 boot sequence?

The 1401 had a boot-from-tape-1 button on the console, and a
boot-from-card button on the card reader. You couldn't truly boot from a
disk; you loaded a little starter deck of about 20 cards on the card reader.

On the 1401, the typewriter was an optional luxury, mainly used in long
batch jobs to do ad-hoc on-line queries. On the compatible 1460, the
typewriter was somewhat more common, because the console the typewriter
mounted on was a standard part of the system, so only the typewriter had
to be added.

--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

 

[Martin Gregorie]

No, most S/360s used microcode.

I never used an S/360.

I thought microcode came into the IBM world with S/370 and Future Series
(which later reappeared as the AS/400, which I did use). Didn't the S/370
load its microcode off an 8 inch floppy?

 

[John W Kennedy]

I never used an S/360.

I thought microcode came into the IBM world with S/370 and Future Series
(which later reappeared as the AS/400, which I did use). Didn't the S/370
load its microcode off an 8 inch floppy?

Some did, but not all. The 370/145 was the first, and made a big splash
thereby.

As to the 360s:

20 (Incompatible subset) I don't know
22 (Recycled end-of-life 30) CROS
25 Loaded from punched cards
30 CROS
40 TROS
44 (Subset) None
50 CROS
60, 62, 65 ROS
64, 66, 67 ROS
70, 75 None
85 I don't know
91, 95 I don't know -- probably none
195 I don't know

CROS used plastic-coated foil punched cards as the dielectrics of 960
capacitors each.

TROS used little transformer coils that might or might not be severed.

ROS means it was there, but I don't know the technology.
--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only
the obeisance of others! Thus is bad government born! Hold in your
heart that you and the people are one, human beings all, and good
government shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)