Re: Question - about "nn-bit" and instruction "speed"
From: Joe Zitzelberger (joe_zitzelberger_at_nospam.com)
Date: 09/28/04
- Next message: Arnold Trembley: "Re: Question - about "nn-bit" and instruction "speed""
- Previous message: Don Leahy: "Re: cics and batch"
- In reply to: William M. Klein: "Question - about "nn-bit" and instruction "speed""
- Next in thread: Arnold Trembley: "Re: Question - about "nn-bit" and instruction "speed""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Sep 2004 22:45:58 -0400
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 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".
- Next message: Arnold Trembley: "Re: Question - about "nn-bit" and instruction "speed""
- Previous message: Don Leahy: "Re: cics and batch"
- In reply to: William M. Klein: "Question - about "nn-bit" and instruction "speed""
- Next in thread: Arnold Trembley: "Re: Question - about "nn-bit" and instruction "speed""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
