Cobol - Question - about "nn-bit" and instruction "speed"

Author

Question - about "nn-bit" and instruction "speed"

William M. Klein

2004-10-02, 8:55 am

This is a follow-up on another thread and my ignorance in this area is so great
that I am not certain that I can even formulate an "intelligent" question.

Preamble:
I do NOT claim to understand *any* hardware or operating system at any depth.
It always amazes me that machines that can (basically) just understand "on and
off" can do everything that computers can do!

Furthermore, the only hardware and operating system that I ever came CLOSE to
understanding was IBM's MVS (post-S/360) systems.

In that environment, I have gone thru 24-bit to 31-bit (not 32-bit)
architectural changes and am at least semi-informed on their current 64-bit
architecture. I understand AMODE versus RMODE and this was part of what
prompted me to write this note.

I was going to reply to another note with the statement that in z/Architecture
there is AMODE(64) support, but no RMODE(64) support - and that IBM has
indicated that there probably never will be RMODE(64) support.

I have also been a user and/or worked with 16-bit, 32-bit, and/or 64-bit OS/2,
Windows, *nix or variations thereof.

***

All of this comes down to the fact that "nn-bit" seems to mean/do different
things in different operating systems and on different hardware.

For IBM mainframes, "data files" are handled totally (or almost totally)
independent of "addressing mode". "Program data" is reflected by AMODE and
instruction location is reflected by RMODE. (This is a simplification and isn't
quite correct - but it is close enough for this note). When IBM went from MVS
to MVS/XA, they allowed for data to be "above the line" when instructions were
still below. They also provided a way for instructions to be above the line
(which had a pre-req of data above the line). With 64-bit, they have provided
for data above the bar - but not instructions.

Now in C and C-interacting languages (on "workstation" type OS/hardware), it
seems that 16-/32-/64-bit changes the size of pointers and integers. It also
allows for larger files as they have different file systems (between 16-bit and
32-bit intel) and because the "data" in the files can now be addressed by a
larger pointer. There are certainly other ramifications of the changes in this
hardware and OS, but I don't know about all of that.

I am also aware that historically there were 6-/7-/8-bit machines - where a
"character" was different sizes -- and I believe that "words" were also
different sizes.

***

Now my real question is what does ANY of this "nn-bit" have to do with how
"machine instructions" are processed? Does a "64-bit machine" *always* take in
64-bit's of data when processing each "cycle" of machine instruction? Is there
a difference between meanings of "64-bit" machines as to "addressing" versus
"instruction" processing? Is it simply a matter that when machines start to get
"bigger" for addressing that they also get "faster" for instruction processing?
Does any of this have to do with the IBM mainframe "PSW" changes in 64-bit mode?

Again, sorry if these questions don't even make sense. It is simply that I
understand "nn-bit" for addressing (based on my IBM mainframe background) but
don't understand it for "instruction processing".

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2004-10-03, 8:55 am

Really enjoyed this Arnold... Thanks for posting it.

Some comments below...

"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:6h46d.444984$OB3.18815@bgtnsc05-news.ops.worldnet.att.net...
>
>
> William M. Klein wrote:
so great[color=darkred]
question.[color=darkred]
any depth.[color=darkred]
>
> I don't claim to know any more than you do, but I will be happy to add
> to the general misinformation...

That's what I love about CLC <G>...

>
how[color=darkred]
take in[color=darkred]
Is there[color=darkred]
versus[color=darkred]
start to get[color=darkred]
processing?[color=darkred]
64-bit mode?[color=darkred]
>
> Mr. Klein, you sure ask a lot of questions!
>
> Way back when I was in programming school (in 1978), I had a textbook
> that asserted the IBM 360 was "a byte-addressable machine with a
> 32-bit word size".
>
> I once read a long usenet thread debating what the size of a byte was,
> but in the IBM mainframe world a byte was an 8-bit binary number in
> which one character could be stored. As far as I know, the IBM 360
> (with the possible exceptions of the very low-end models) was
> considered to be a 32-bit machine, because it could fetch 32-bits of
> memory at a time.

Er... not if memory serves me correctly. It fetched a single byte of memory
(I seem to recall our 360/30 did this in 1.5 microseconds (and we thought it
was the greatest thing since sliced bread), but it's registers could load a
31 bit ADDRESS.)

The actual fetching was done by a piece of hardware called the Arithmetic
Logic Unit (ALU) and this had 9 data pathways. (8 for data and 1 for
parity).

It's all pretty irrelevant now anyway...

Of course, you and I are both well aware that size
> of an address on the IBM 360 was just 24 bits. Only later was the
> architecture enhanced to support 31-bit addresses (not 32-bit). A
> System 360 machine instruction could be 16 bits, 32 bits, or 48 bits
> in length, depending on format. Those same instructions still work an
> a 64-bit z990 mainframe (in 31-bit mode).

Yes, that gels with my experience to the best of my recollection.
>
> The orginal IBM PC used the Intel 8088 microprocessor, which had an
> 8-bit data bus (memory fetch was one 8-bit byte at a time), with a
> 20-bit address argument. The 8086 (used in some IBM PS/2 computers)
> had a 16-bit data bus (memory fetch was one 16-bit word at a time) but
> still had the 20-bit address argument. Both of these were generally
> considered to be 16-bit machines. I'm vague on the details of the
> 80286, but the 80386, 486, and early pentiums are generally considered
> to be 32-bit machines (I think). The earlier Intel 8080, Zilog Z80,
> motorola 6800, and Mostek 6502 microprocessors were generally
> considered to be 8-bit machines with 16-bit address arguments.
>
> There doesn't seem to be much consistency here, but I would assume
> that a modern 64-bit processor will fetch memory in 64-bit chunks (or
> larger), and will probably support a 64-bit address argument (or some
> value between 32 bits and 64 bits).
>
> All else being equal (which it isn't), a processor that fetches memory
> in 64-bit chunks is faster than one that fetches 32-bit chunks, which
> is faster than 16 bits or 8 bits. This assumes that it takes the same
> number of clock cycles to do one memory fetch.

Yes, I believe that's the key to it. How many memory cycles does it take?

I well remember in the age of Chaos, before even bytes were standardised at
8 bits, there was fierce competition between IBM and ICL.

IBM were pushing for the 8 bit byte; ICL had a 24 bit word which they
considered to be 4 characters of 6 bits each. (The CDC Cyber series used a 6
bit character based on a 64 bit word at around the same time). Both of the 6
bit machines were much faster than the IBM 8 bit machine.

(It was kind of ironic because the 360 used 3rd generation IC technology and
both the Cyber and the ICL 1900 were still in second generation TTL logic.
The Cyber was designed by the legendary Seymour Cray, the IBM by the equally
legendary Gene Amdahl, and the ICL by a committeee in Putney (probably...
<G> ))

ICL actually considered using the same 24 bit word hardware and considering
it to be 3 bytes. I heard rumours when I worked for them at Stevenage (many
years later) that prototypes were built, but these stories could be
apochryphal.

Leaving the Cyber out of it (and it isn't fair to compare an F16 with an MG,
even though both machines have appeal), you might wonder how the "6 bit "
character ICL machine consistently creamed the IBM opposition which was
using an 8 bit architecture. The IBM had a bigger byte and so could
accommodate a larger character set without having to introduce shift
characters into strings, and the IBM had a multi address instruction set
(each instruction (SS type) contained the addresses of all its operands,
while the ICL machine needed to load everything into registers before it
could do anything with it.

Salesmen being salesmen (donch'a jus' LOVE 'em?) the IBMers went to great
pains to sound knowledgeable and impress their prospects with the fact that
"due to its much more powerful instruction set, and the latest emerging
standard 8 bit byte technology", their baby could do the same task as the
ICL machine with a fraction of the instructions, and so it was definitely
superior.

All well and good until we ran the benchmarks...

ICL hosed them to the point of embarassment.

It all comes down to how many machine cycles you need to do, to execute a
given instruction, and how fast you can do 'em.

(and that's where I came in, above.)

Certainly, the "gulp" of memory you can take to fetch an instruction may
have a bearing on this, so 64 bit fetch is probably better than 32, but that
is not the Holy All of it. (If it were, we would be running 1024 byte
architectures... maybe we will one day, but my feeling is that there is a
cut-off point where diminishing returns cut in, and it makes more sense to
go to parallel processors...) If you have a brilliant architecture with
small, very fast instructions, you may very well outperform a "more
powerful" architecture that requires many more cycles to execute. The ICL
machines could do their LDX (Load Register) and STO (Store) instructions
many times, while the poor old 360 was still stepping through its ROS (Read
Only Storage) to decide how to decipher an Op Code. Amdahl's dream of a
totally "soft" and "flexible" machine that could have its instruction set
extended and modified at minimal cost was realised, but the down side was
slower execution.

(This "oversight" was corrected in upper 360 models and by the time 370
arrived, the whole idea of ROS was obsolete. Firmware technology was
available that was many times more powerful than mylar cards...)

The wisdom embodied in the above was "re-discovered" years later when it
became apparent that RISC (Reduced Instruction Set Computer) processors
were many times faster than CISC (Complex Instruction Set Computers).

Like Betamax, both RISC and ICL seem to have gone the way of whoever comes
second in the marketing race... You can have the best technology, you can
demonstrate that you have the best technology, but if the crap stuff is
marketed better, you are on a hiding to nothing... (COBOL suffers from this
to some degree; nobody is marketing it effectively and the people who are
supposed to be responsible for it, aren't.)

>
> Modern processors usually have a large cache of very fast memory to
> hold instructions or data, where the original IBM 360 only had sixteen
> 32-bit general registers of fast memory for data or addresses. I was
> never taught that IBM 360 had cache memory for instructions.
>

That's because it didn't... <G> "Memory" consisted of core storage. Ferrite
doughnuts strung painstakingly onto fine wire lattices, by sweat shops in
Korea, where people went blind with the strain of peering for many hours
into microscopes while mainpulating said wires and doughnuts. Memory was
more expensive than diamonds. Machines costing sometimes over a million
dollars (and that was when a million dollars would buy more than a good
night on the town) came with 32KB as standard. (Ours had 16 KB, but they
were a pretty cheap company <G>. Nevertheless they paid over $350,000 for
it, and had to upgrade it later.) The Operating system (I'm thinking TOS and
DOS here) took 6 KB.
(I remember some of us being really awed by the news that Apollo 9 (I think
it was...) had 512 KB of memory on board, and they had managed to fit it all
into something the size of a coffee pot...Stop fiddling with the 1GB flash
card on your key chain... <G> )

> Everything is faster these days (clock cycles, memory fetch time,
> instruction cycles, I/O devices), and having a wider data bus is only
> one thing that makes modern processors faster.
>
> Are we thoroughly

yet?
>

It's a normal state for me... <G> I rationalise it by deciding that I try to
see all points of view, but the inner me isn't fooled.

Finally Bill, I was interested in your comment about changes to the PSW.
Does this mean we can't swap states anymore and issue priveleged
instructions <G>....?

Pete.

Arnold Trembley

2004-10-03, 3:55 pm

Pete Dashwood wrote:
> Really enjoyed this Arnold... Thanks for posting it.

Glad you enjoyed. Although I wonder why your post dated September
29th just now showed up in my newsreader on October 3rd. Must be my
ISP...

> (snip)

With apologies to Mr. Klein, and no offense intended, but this was a
takeoff of Gilda Radner's old "Rosanne Rosanna-Danna" bit from the
Saturday Night Live TV show. CLCer's outside the USA will probably
still be mystified.

[color=darkred]
>
>
> Er... not if memory serves me correctly. It fetched a single byte of memory
> (I seem to recall our 360/30 did this in 1.5 microseconds (and we thought it
> was the greatest thing since sliced bread), but it's registers could load a
> 31 bit ADDRESS.)

Well, I could certainly be wrong, but the register size on IBM-360 was
32 bits. Seems awfully inefficient to require 4 memory fetches to
load a 32-bit general purpose register. :-)

> (more snippage)
> Finally Bill, I was interested in your comment about changes to the PSW.
> Does this mean we can't swap states anymore and issue priveleged
> instructions <G>....?
>
> Pete.

I have never read the PoPs manual (Principles of Operation) for any
version of IBM mainframe, but I believe the PSW had to be "widened"
quite a bit to support 64-bit addressing mode. Programs running in
24-bit or 31-bit mode only see the old-style PSW (I think).

Perhaps someone more knowledgeable than me will jump in and clarify this.

With kindest regards,

--
http://arnold.trembley.home.att.net/

William M. Klein

2004-10-04, 3:55 am

This may be a duplicate, but it looks to me as if this didn't get posted when I
tried to post it earlier today. Sorry if it turns out to be a duplicate.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message news:...
> This is a follow-up on another thread and my ignorance in this area is so
> great that I am not certain that I can even formulate an "intelligent"
> question.
>
> Preamble:
> I do NOT claim to understand *any* hardware or operating system at any
> depth. It always amazes me that machines that can (basically) just understand
> "on and off" can do everything that computers can do!
>
> Furthermore, the only hardware and operating system that I ever came CLOSE to
> understanding was IBM's MVS (post-S/360) systems.
>
> In that environment, I have gone thru 24-bit to 31-bit (not 32-bit)
> architectural changes and am at least semi-informed on their current 64-bit
> architecture. I understand AMODE versus RMODE and this was part of what
> prompted me to write this note.
>
> I was going to reply to another note with the statement that in z/Architecture
> there is AMODE(64) support, but no RMODE(64) support - and that IBM has
> indicated that there probably never will be RMODE(64) support.
>
> I have also been a user and/or worked with 16-bit, 32-bit, and/or 64-bit OS/2,
> Windows, *nix or variations thereof.
>
> ***
>
> All of this comes down to the fact that "nn-bit" seems to mean/do different
> things in different operating systems and on different hardware.
>
> For IBM mainframes, "data files" are handled totally (or almost totally)
> independent of "addressing mode". "Program data" is reflected by AMODE and
> instruction location is reflected by RMODE. (This is a simplification and
> isn't quite correct - but it is close enough for this note). When IBM went
> from MVS to MVS/XA, they allowed for data to be "above the line" when
> instructions were still below. They also provided a way for instructions to
> be above the line (which had a pre-req of data above the line). With 64-bit,
> they have provided for data above the bar - but not instructions.
>
> Now in C and C-interacting languages (on "workstation" type OS/hardware), it
> seems that 16-/32-/64-bit changes the size of pointers and integers. It also
> allows for larger files as they have different file systems (between 16-bit
> and 32-bit intel) and because the "data" in the files can now be addressed by
> a larger pointer. There are certainly other ramifications of the changes in
> this hardware and OS, but I don't know about all of that.
>
> I am also aware that historically there were 6-/7-/8-bit machines - where a
> "character" was different sizes -- and I believe that "words" were also
> different sizes.
>
> ***
>
> Now my real question is what does ANY of this "nn-bit" have to do with how
> "machine instructions" are processed? Does a "64-bit machine" *always* take
> in 64-bit's of data when processing each "cycle" of machine instruction? Is
> there a difference between meanings of "64-bit" machines as to "addressing"
> versus "instruction" processing? Is it simply a matter that when machines
> start to get "bigger" for addressing that they also get "faster" for
> instruction processing? Does any of this have to do with the IBM mainframe
> "PSW" changes in 64-bit mode?
>
> Again, sorry if these questions don't even make sense. It is simply that I
> understand "nn-bit" for addressing (based on my IBM mainframe background) but
> don't understand it for "instruction processing".
>
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>

Arnold Trembley

2004-10-05, 3:55 pm

Sponsored Links