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

This is a follow-up on another thread and my ignorance in this area is so gr
eat
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 a
nd
off" can do everything that computers can do!

Furthermore, the only hardware and operating system that I ever came CLOSE t
o
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/Architectu
re
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 i
sn't
quite correct - but it is close enough for this note).  When IBM went from M
VS
to MVS/XA, they allowed for data to be "above the line" when instructions we
re
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 provid
ed
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 als
o
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 t
his
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 th
ere
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 processi
ng?
Does any of this have to do with the IBM mainframe "PSW" changes in 64-bit m
ode?

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) bu
t
don't understand it for "instruction processing".


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

This may be a duplicate, but it looks to me as if this didn't get posted whe
n 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 underst
and
> "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-bi
t
> 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/Architec
ture
> 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 O
S/2,
> Windows, *nix or variations thereof.
>
> ***
>
> All of this comes down to the fact that "nn-bit" seems to mean/do differen
t
> 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 an
d
> 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 wen
t
> 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-b
it,
> 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 a
lso
> allows for larger files as they have different file systems (between 16-bi
t
> 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* ta
ke
> 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
>

On Mon, 27 Sep 2004 16:57:02 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Now my real question is what does ANY of this "nn-bit" have to do with how
>"machine instructions" are processed?

Indirectly. How machine instructions are processed is a function of
microcode design. Horizontal microcode, as used on IA-64, is faster
than vertical because it offers greater parallelism and branch
prediction .. at the price of bigger instructions. When memory was
expensive and bandwidth low, microcode was horizontal. That paradigm
persists even in Pentium and AMD. IA-64 exploits the wider bandwidth
of 64-bit to gain speed. It asks the compiler to package up to three
instructions per frame, then executes three instructions in one clock.

> Does a "64-bit machine" *always* take in
>64-bit's of data when processing each "cycle" of machine instruction?

Basically yes. A program must be able to access bytes, but that's a
special case. A byte takes as long as a word.

>  Is there
>a difference between meanings of "64-bit" machines as to "addressing" versu
s
>"instruction" processing?

Not much. Instructions might be translated into a microop cache and/or
have their operands resolved in advance. Machines with horizontal
microcode and a flat address space, such as IA-64, don't need either.

Outside IBM there's no prohibition against code residing and executing
above the bar. I'm not convinced there is on zOS either. This Web page
says "Well, a significant amount of DB2 V8 code runs above the bar in
AMODE(64). This includes the vast majority of the DBM1 address space
code, the log manager, parts of DDF and tracing."

http://www.dbazine.com/stuhler1.shtml

> Is it simply a matter that when machines start to get
>"bigger" for addressing that they also get "faster" for instruction processing?[/co
lor]

The passage of time makes everything faster due to smaller trace
width. If Intel's instruction set hadn't changed in 20 years, we'd
have 16-bit 8086s almost as fast as a Pentium (but not capable of
efficient multitasking).

Architecture can turn bigger into faster, as in the case of IA-64.

IMHO, trying to understand how the system works based upon bit, word or
character size is not possible. Word, or character size is like a
highway. You have so many lanes, based upon number of bits. You have
a clock ticking off at a certain speed that is reflected in different
components as required.

The other elements of the hardware, of which there may be  many, have
all sorts of function in the timing, processing, and execution of
instructions. The only relationship between the size of the path
(highway), and anything else is related to storage, timing, and other
hardware processes to implement the instruction set(s).

Of course, the larger the size of an operand reflects itself in the
ability of the calculation of results, and timing of various functions,
and the speed with which input and output might be processed.

Warren Simmons


William M. Klein wrote:
> 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 CLOS
E 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-bi
t
> 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/Architec
ture
> 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 O
S/2,
> Windows, *nix or variations thereof.
>
> ***
>
> All of this comes down to the fact that "nn-bit" seems to mean/do differen
t
> 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 an
d
> 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 li
ne
> (which had a pre-req of data above the line).  With 64-bit, they have prov
ided
> 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 a
lso
> allows for larger files as they have different file systems (between 16-bi
t 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* ta
ke 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" vers
us
> "instruction" processing?  Is it simply a matter that when machines start 
to get
> "bigger" for addressing that they also get "faster" for instruction proces
sing?
> 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".
>
>

I'll take a shot at addressing (pun intended, of course) this if I may.

The terms 24- 31-bit, relating to IBM mainframes refer, to the address
size.  While the chip that processed those addresses and related
instructions was known as a 32-bit CPU.  That is because the CPU could
make reference to 32 separate bits per cycle -- regardless of the memory
architecture.

When a CPU is described as n-bit, usually n is the width of the general
purpose registers.  In the case of the S360, it could always, for
example, do an add of two 32-bit words in a single instruction, so it
was known as a 32-bit chip.

Really, these are two different things that happen to use the same
terminology.  It is possible to have a 24-bit (16M) addressing scheme
with an 8-bit chip (like the 65C02 Apple ][ line) or a 32-bit chip that
is limited to only addressing 20-bits (1 Meg) of memory, like many early
80386 machines.  It really depends on the hardware manufacturer.



In article <yDX5d.2213256$6p.374337@news.easynews.com>,
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

> 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 CLOS
E
>  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-bi
t
> 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 differen
t
> 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 an
d
> 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 li
ne
> (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 a
lso
> allows for larger files as they have different file systems (between 16-bi
t
> 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* ta
ke
> 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" vers
us
> "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".

William M. Klein wrote:
> 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.[/
color]

I don't claim to know any more than you do, but I will be happy to add
to the general misinformation...

> (snip)
> 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* ta
ke 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" vers
us
> "instruction" processing?  Is it simply a matter that when machines start 
to get
> "bigger" for addressing that they also get "faster" for instruction proces
sing?
> Does any of this have to do with the IBM mainframe "PSW" changes in 64-bit mode?[/
color]

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.  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).

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.

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.

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?

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