| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 104:21:28 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,612 |
In early computer designs, arithmetic registers were much longer than addresses, the classic examples being machines with 36-bit words and
15- to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had
32-bit arithmetic registers and 32-bit address registers. You
couldn't put 32-bits worth of physical memory in a machine for over a
decade after it appeared, but it was allowed for in the architecture.
Nowadays, the bit-ness of a machine seems to be the *smaller* of the arithmetic registers and the address space. This became true in the
early 1970s, as far as I can see, and the terminology became confused
around then. A few examples from that period:
Classic "8-bit" microprocessors, such as the 8080 or 6800 have 8-bit arithmetic and 16-bit addressing.
The PDP-11 has 16-bit arithmetic and 16-bit addressing, plus
bank-switching.
The original 8086 has 16-bit arithmetic and a strange 20-bit
addressing scheme.
Modern architectures have arithmetic and address registers that are
the same size.
John
In early computer designs, arithmetic registers were much longer than >addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit >arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it >appeared, but it was allowed for in the architecture.
In early computer designs, arithmetic registers were much longer than addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it appeared, but it was allowed for in the architecture.
On 2024-11-28, John Dallman <jgd@cix.co.uk> wrote:
In early computer designs, arithmetic registers were much longer than
addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit
arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it
appeared, but it was allowed for in the architecture.
The original /360 had a 24-bit address space. The plan had been
to make it 32-bit clean, but some people didn't get the memo, reasulting
in a lot of hassle later on.
In early computer designs, arithmetic registers were much longer than addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it appeared, but it was allowed for in the architecture.
Nowadays, the bit-ness of a machine seems to be the *smaller* of the arithmetic registers and the address space.
On Thu, 28 Nov 2024 17:56:23 +0000, Thomas Koenig wrote:
On 2024-11-28, John Dallman <jgd@cix.co.uk> wrote:
In early computer designs, arithmetic registers were much longer than
addresses, the classic examples being machines with 36-bit words and 15- >>> to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit
arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it >>> appeared, but it was allowed for in the architecture.
The original /360 had a 24-bit address space. The plan had been
to make it 32-bit clean, but some people didn't get the memo, reasulting
in a lot of hassle later on.
BAL -> BAS , ...
And assembly people using the upper 8-bits of base registers for "interesting" things.
In early computer designs, arithmetic registers were much longer than addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it appeared, but it was allowed for in the architecture.
Apple went through the same sort of thing. Yet it managed the
transition much more cleanly.
This in spite of having an installed base that was orders of
magnitude larger than the IBM System/360 family.
The original /360 had a 24-bit address space. The plan had been to make
it 32-bit clean, but some people didn't get the memo, reasulting in a
lot of hassle later on.
Apples and oranges. IBM had fewer but much larger customer organisations,
and could not afford to upset them much. Most IBM mainframe shops write
some software themselves; that wasn't the case for Apple users in the
1980s.
At the time, IBM had the "Future System" project that was planning
on doing just that ... and I assumed that was what he was referring
to ... however in later years he claimed that he never had any
knowledge about "FS" (and had left IBM before it started).
In article <viao3r$na9e$4@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
Apple went through the same sort of thing. Yet it managed the
transition much more cleanly.
Apple simply demanded all software become 32-bit clean. The fact that
they didn't forsee the problem and warn software writers not to use the
high 8 bits rather implies they weren't paying attention.
This in spite of having an installed base that was orders of
magnitude larger than the IBM System/360 family.
Apples and oranges. IBM had fewer but much larger customer
organisations, and could not afford to upset them much.
In early computer designs, arithmetic registers were much longer than >addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
Large logical address spaces started with the IBM 360, which had 32-bit >arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it >appeared, but it was allowed for in the architecture.
Nowadays, the bit-ness of a machine seems to be the *smaller* of the >arithmetic registers and the address space. This became true in the early >1970s, as far as I can see, and the terminology became confused around
then. A few examples from that period:
Classic "8-bit" microprocessors, such as the 8080 or 6800 have 8-bit >arithmetic and 16-bit addressing.
The PDP-11 has 16-bit arithmetic and 16-bit addressing, plus
bank-switching.
The original 8086 has 16-bit arithmetic and a strange 20-bit addressing >scheme.
Modern architectures have arithmetic and address registers that are the
same size.
In the early 1980s the width of the data bus of the main
implementation of an architecture was considered to be defining the
bitness of the architecture. This is especially noticable in the
68000, which was usually described as 16-bit CPU, despite having
32-bit address and 32-bit data registers, because it has a 16-bit data
bus. I think that even Motorola called it a 16-bit CPU. With low-cost variants such as the 8088, the 68008, and later the 386SX, that idea
was not kept up.
On Thu, 28 Nov 2024 22:08 +0000 (GMT Standard Time), John Dallman wrote:
In article <viao3r$na9e$4@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
Apple went through the same sort of thing. Yet it managed the
transition much more cleanly.
Apple simply demanded all software become 32-bit clean. The fact that
they didn't forsee the problem and warn software writers not to use the
high 8 bits rather implies they weren't paying attention.
Oh, they were paying attention, all right. In the original 1984 Macintosh software, the top 8 bits in a “handle” (pointer to a pointer to a relocatable block) were used to store handle state (e.g. whether the block was locked in a particular memory location). But there were no API calls
to save/restore this state. That was fixed in the Mac Plus in 1986. So all had to happen was for app developers to use the new calls, instead of
peeking at bits directly.
This in spite of having an installed base that was orders of
magnitude larger than the IBM System/360 family.
Apples and oranges. IBM had fewer but much larger customer
organisations, and could not afford to upset them much.
IBM had legendary market power, all the way up to monopoly status.
Whatever it decreed, its market had to follow.
S/360 normally referred as 24-bit address architecture.
S/370 normally referred as 31-bit address architecture.
I don't know technical reasons for it, but would think that they exist.
IBM had legendary market power, all the way up to monopoly status.
Whatever it decreed, its market had to follow.
According to Michael S <already5chosen@yahoo.com>:
S/360 normally referred as 24-bit address architecture.
S/370 normally referred as 31-bit address architecture.
I don't know technical reasons for it, but would think that they exist.
S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
the high 8 bits of the register were ignored. That turned out to be a really bad
decision since a few instructions and a lot of programming conventions stored other stuff in that high byte, causing severe pain a few years later when memories got bigger than 16 meg. The kludge in S/370 was to use the high bit as
a flag, 0 meant 24 bit addressing, 1 meant 31 bit addressing. That worked reasonably well although they came up with yet more kludges to let programs switch among multiple 31-bit address spaces.
They finally bit the bullet in 2000
when they announced zSeries with 64 bit addresses and registers.
These days I'd say the relevant N is the size of arithmetic registers but a lot of marketers appear to disagree with me.
S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic >the high 8 bits of the register were ignored. That turned out to be a really bad
decision since a few instructions and a lot of programming conventions stored >other stuff in that high byte, causing severe pain a few years later when >memories got bigger than 16 meg.
These days I'd say the relevant N is the size of arithmetic registers but a >lot of marketers appear to disagree with me.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic registers but a >>>lot of marketers appear to disagree with me.
Which arithmetic registers on an Intel processor? The 64 bits of a
GPR? The 128 bits of an XMM register? The 256 bits of a YMM
register? The 512 bits of a ZMM register?
The Cray-1 is even more interesting in that respect. Is it a 4096-bit machine?
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic registers but a >>lot of marketers appear to disagree with me.
Which arithmetic registers on an Intel processor? The 64 bits of a
GPR? The 128 bits of an XMM register? The 256 bits of a YMM
register? The 512 bits of a ZMM register?
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic registers but a >>>>lot of marketers appear to disagree with me.
Which arithmetic registers on an Intel processor? The 64 bits of a
GPR? The 128 bits of an XMM register? The 256 bits of a YMM
register? The 512 bits of a ZMM register?
The Cray-1 is even more interesting in that respect. Is it a 4096-bit
machine?
If you consider the widest arithmetic it is capable of in one piece,
it is a 64-bit machine.
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
Which arithmetic registers on an Intel processor? The 64 bits of a >>>GPR? The 128 bits of an XMM register? The 256 bits of a YMM
register? The 512 bits of a ZMM register?
The Cray-1 is even more interesting in that respect. Is it a
4096-bit machine?
If you consider the widest arithmetic it is capable of in one piece,
it is a 64-bit machine.
That's not John Levine's criterion.
BTW, with your criterion, the Zen5 in the Ryzen AI 370HX is a 256-bit machine, while the Zen5 in the Ryzen 9600X is a 512-bit machine.
According to John Levine's criterion they are both 512-bit machines. According to me they are both 64-bit machines. John Levine's and my
criteria are architectural, yours is implementation-oriented.
- anton
John Levine <johnl@taugh.com> writes:
S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
the high 8 bits of the register were ignored. That turned out to be a really bad
decision since a few instructions and a lot of programming conventions stored >>other stuff in that high byte, causing severe pain a few years later when >>memories got bigger than 16 meg.
The technique of putting stuff in unused bits of an address has its >drawbacks, but it also has benefits, in particular type information is
often stored there (even on architectures that do not ignore any
bits). Of course AMD and Intel have the bad examples of S/360 and
68000 in mind, and did not want to have anything to do with that
during the first two decades of AMD64.
The designers of ARM A64 could think beyond that and designed in the >top-byte-ignore feature. Apparently this made AMD and Intel see the
light:
AMD added the upper-address ignore feature, which, when enabled,
ignores the top 7 bits. One problem with this in the Linux kernel
(and maybe other OSs) is that the Linux kernel expects the top bit to
be set only for kernel addresses. Not sure how that works with ARMs
top-byte ignore feature, which is supported since Linux 5.4 in 2019
using the PR_SET_TAGGED_ADDR_CTRL option of the prctl() call.
Intel added the linear address masking feature, with two variants:
LAM_U57 ignores bits 57-62 (but not the MSB), allowing 6 bits for
other uses; LAM_U48 ignores bits 48-62, allowing 15 bits for other
uses. These variants require bit 63 to have the same value as bit
56/47; another bit could be made available by ignoring bit 56/47 (the >information is in bit 63 anyway), but Intel apparently decided that >programmers don't need that extra bit.
On Sat, 30 Nov 2024 16:57:56 GMT...
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
John Levine said "arythmetic". Not logic, not move, not swizzle, not >load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs and
128 bits for output (integer multiplication).
Michael S <already5chosen@yahoo.com> writes:
On Sat, 30 Nov 2024 16:57:56 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
...Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
John Levine said "arythmetic". Not logic, not move, not swizzle, not >load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs
and 128 bits for output (integer multiplication).
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each. Sure, they are used for arithmetic on a sequence of individually narrower data, but the registers have 512
bits nonetheless.
- anton
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each. Sure, they are used for arithmetic on a >sequence of individually narrower data, but the registers have 512
bits nonetheless.
a flag, 0 meant 24 bit addressing, 1 meant 31 bit addressing. That worked
reasonably well although they came up with yet more kludges to let programs >> switch among multiple 31-bit address spaces.
Was ESA one of those kludges?
These days I'd say the relevant N is the size of arithmetic registers but a >> lot of marketers appear to disagree with me.
I tend to agree with you, with the caveat, as Mitch pointed out, of SIMD >registers. But I suspect the term N-bit machine, will soon be a
historic relic, as most architectures have converged on 64 bit
arithmetic registers, and with the growth of address spaces seeming to
slow down, it will be a long time before anyone goes to 128 bit
(non-SIMD) registers.
According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
a flag, 0 meant 24 bit addressing, 1 meant 31 bit addressing. That
worked reasonably well although they came up with yet more kludges
to let programs switch among multiple 31-bit address spaces.
Was ESA one of those kludges?
I'd say that was the main kludge, with primary and secondary address
spaces and address registers that worked sort of like segment
registers paired with the address in each regular register.
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
I tend to agree with you, with the caveat, as Mitch pointed out, of
SIMD registers. But I suspect the term N-bit machine, will soon be
a historic relic, as most architectures have converged on 64 bit
arithmetic registers, and with the growth of address spaces seeming
to slow down, it will be a long time before anyone goes to 128 bit >(non-SIMD) registers.
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
Michael S <already5chosen@yahoo.com> writes:
On Sat, 30 Nov 2024 16:57:56 GMT...
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
John Levine said "arythmetic". Not logic, not move, not swizzle, not >>load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs and >>128 bits for output (integer multiplication).
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each.
Sure, they are used for arithmetic on a
sequence of individually narrower data, but the registers have 512
bits nonetheless.
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
On Sat, 30 Nov 2024 19:40:17 +0000, John Levine wrote:
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
Still one hardly needs more than a Z80 to run a toaster, microwave,
stove,
oven, faucet, door lock, refrigerator, ... {{Or basically everything
nobody
ever thought would have/need a computer inside of them}}
I recently read that 6502 processors are still in use in pacemakers.
You just hope that there is no stack overflow...
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Michael S <already5chosen@yahoo.com> writes:
On Sat, 30 Nov 2024 16:57:56 GMT...
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
These days I'd say the relevant N is the size of arithmetic
registers but a lot of marketers appear to disagree with me.
John Levine said "arythmetic". Not logic, not move, not swizzle, not >>>load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs and >>>128 bits for output (integer multiplication).
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each.
Can you do a 512-bit addition with it natively?
I meant the main registers, for some straightforward version of main.
You are of course correct that there are special purpose registers
that are much wider but I don't think it's all that hard to see which
ones I meant.
Everyone agreed that all the models of S/360 were 32 bit machines, but the >implementations ranged from 8 bits for the /25 and /30 to 64 bits for
the /75.
On Sat, 30 Nov 2024 18:08:58 GMT...
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each. Sure, they are used for arithmetic on a
sequence of individually narrower data, but the registers have 512
bits nonetheless.
8x64 is not the same as 512.
You don't call 2-way superscalar 64-bit CPU 128-bit.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
John Levine <johnl@taugh.com> writes:
S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
the high 8 bits of the register were ignored. That turned out to be a really bad
decision since a few instructions and a lot of programming conventions stored
other stuff in that high byte, causing severe pain a few years later when >>>memories got bigger than 16 meg.
The technique of putting stuff in unused bits of an address has its >>drawbacks, but it also has benefits, in particular type information is >>often stored there (even on architectures that do not ignore any
bits). Of course AMD and Intel have the bad examples of S/360 and
68000 in mind, and did not want to have anything to do with that
during the first two decades of AMD64.
The designers of ARM A64 could think beyond that and designed in the >>top-byte-ignore feature. Apparently this made AMD and Intel see the
light:
AMD added the upper-address ignore feature, which, when enabled,
Architecturally known as Top Byte Ignore (TBI). It can be
independently enabled for each half of the virtual address space
(based on the value of VA<55>).
ignores the top 7 bits.
Michael S <already5chosen@yahoo.com> writes:
On Sat, 30 Nov 2024 18:08:58 GMT...
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
registers with 512 bits each. Sure, they are used for arithmetic on a
sequence of individually narrower data, but the registers have 512
bits nonetheless.
8x64 is not the same as 512.
Alternative facts?
I think "ALU can add up to n-bit numbers" is a reasonable definition
for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
John Levine <johnl@taugh.com> writes:
I meant the main registers, for some straightforward version of main.
You are of course correct that there are special purpose registers
that are much wider but I don't think it's all that hard to see which
ones I meant.
I guess you mean the general-purpose registers, which is not a proper >definition, either, and it means that the criterion only applies to >architectures with general-purpose registers.
I tried to be more precise and as a criterion "address register size",
i.e., the size of a register that holds an address. And I guess that
should be refined to the size of a register that holds one address (to
avoid the issue of vector registers containing addresses for
scatter/gather instructions). This also makes it clear that this
criterion does not apply to machines like the IBM 704 and PDP-10 that
have two addresses per machine word, but for word-addressed machines
the word size makes it clear what is meant with "N-bit machine". This >resulta in:
1) For word-addressed machines: the size of the word.
2) For byte-addressed machines: the size of a register that contains
one address.
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition
for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
To me, the phrase "n-bit architecture" should depend only on such characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable
definition for an n-bit architecture, which also fits the 16-bit
68000. It does not fit the 360/30, or the Nova (but see de
Castro's remark on the latter).
To me, the phrase "n-bit architecture" should depend only on such characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
On the other hand, I have right before me a book with the title
"MC68000 16-BIT MICROPROCESSOR User's manual third edition", ISBN 0-13-566695-3 (in paperback). One may argue that the authors
of that book didn't know what they were writing about (since the
68000 has a 32-bit ISA), but I would try to define the terms in
such a way that this is also included.
On 11/30/24 3:38 PM, Michael S wrote:
On Sat, 30 Nov 2024 19:40:17 -0000 (UTC)[snip]
John Levine <johnl@taugh.com> wrote:
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
I agree with conclusions, but not with your examples.
IMHO, the whole ARM Cortex-R series is solution looking for problem. It
could be quite easily replaced by 64-bit A series cores.
Now Cortex-M is completely different story. Here 64-bit cores would not
be appropriate.
I wonder if a 32-bit version of AArch64 would have been
appropriate for the Cortex-R series.
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition
for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
To me, the phrase "n-bit architecture" should depend only on such
characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
On the other hand, I have right before me a book with the title
"MC68000 16-BIT MICROPROCESSOR User's manual third edition", ISBN 0-13-566695-3 (in paperback). One may argue that the authors
of that book didn't know what they were writing about (since the
68000 has a 32-bit ISA), but I would try to define the terms in
such a way that this is also included.
On Sat, 30 Nov 2024 19:40:17 +0000, John Levine wrote:
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
Still one hardly needs more than a Z80 to run a toaster, microwave,
stove,
oven, faucet, door lock, refrigerator, ... {{Or basically everything
nobody
ever thought would have/need a computer inside of them}}
On 12/2/24 3:48 AM, Terje Mathisen wrote:
MitchAlsup1 wrote:Back in the early 1990s when my group first developed what would become
On Sat, 30 Nov 2024 19:40:17 +0000, John Levine wrote:
I get the impression that we will have 32 bit architectures for a very >>>> long time, since they are smaller and cheaper to implement than 64 bit >>>> and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
Still one hardly needs more than a Z80 to run a toaster, microwave,
stove,
oven, faucet, door lock, refrigerator, ... {{Or basically everything
nobody
ever thought would have/need a computer inside of them}}
They are still going to end up with a 32-bit CPU in future products!
Both because that's needed to support a full development environment/
arbitrary languages and because the cost is becoming mostly trivial:
When every single flash/thumb drive has contained a full 32-bit CPU
for more than 5 years now, the cost has to be in the cents range.
Terje
the Motorola MCore, our target was radio (and cell phone) processors.
The intention was to replace the zoo of 16-bit hard to program
processors with a 32-bit processor that was easy to program via
compilers. The additional address space was going to be needed for
protocol stacks (such as IP/TCP) and support of USB stuff. Even with
the silicon nodes at the time, the resulting processor was not much
bigger than bonding pads.
I agree with Terje, no need to have anything less than 32-bit in embedded.
MitchAlsup1 wrote:
On Sat, 30 Nov 2024 19:40:17 +0000, John Levine wrote:
I get the impression that we will have 32 bit architectures for a very
long time, since they are smaller and cheaper to implement than 64 bit
and for a lot of embedded applications they are more than adequate.
Examples are ARM Cortex-R4 and -R5, high performance 32 bit realtime
chips.
Still one hardly needs more than a Z80 to run a toaster, microwave,
stove,
oven, faucet, door lock, refrigerator, ... {{Or basically everything
nobody
ever thought would have/need a computer inside of them}}
They are still going to end up with a 32-bit CPU in future products!
Both because that's needed to support a full development environment/ arbitrary languages and because the cost is becoming mostly trivial:
When every single flash/thumb drive has contained a full 32-bit CPU for
more than 5 years now, the cost has to be in the cents range.
John Levine <johnl@taugh.com> writes:
I meant the main registers, for some straightforward version of main.
You are of course correct that there are special purpose registers
that are much wider but I don't think it's all that hard to see which
ones I meant.
I guess you mean the general-purpose registers, which is not a proper definition, either, and it means that the criterion only applies to architectures with general-purpose registers.
I tried to be more precise and as a criterion "address register size",
i.e., the size of a register that holds an address. And I guess that
should be refined to the size of a register that holds one address (to
avoid the issue of vector registers containing addresses for
scatter/gather instructions). This also makes it clear that this
criterion does not apply to machines like the IBM 704 and PDP-10 that
have two addresses per machine word, but for word-addressed machines
the word size makes it clear what is meant with "N-bit machine". This resulta in:
1) For word-addressed machines: the size of the word.
2) For byte-addressed machines: the size of a register that contains
one address.
These criteria agree with the usual understanding of the bitness of an architecture for most architectures, with a few exceptions:
* The 68000 would be classified as 32-bit architecture, which agrees
with the modern understanding, but not with the marketing as 16-bit
CPU or 16/32-bit CPU at the time.
* Most CPUs described as 8-bit CPUs keep at least the program counter
in a larger register, a number of them (6800, 8008 and its
descendents) also have 16-bit data-address registers or
register-pairs (at least HL for the 8008). At the time they and the
68000 were described as 8-bit (16-bit for the 68000) based on the
implementation of having an 8-bit data bus, but that argument broke
down with the 8088 and 68008.
* I am not that familiar with the old character-oriented
architectures, such as the IBM 702; they apparently are not
described as N-bit machines for any N, so we probably don't need to
assign such a label to them nowadays.
* There were also fixed-word-length machines that were not binary,
such as the IBM 7070. Memory is described as consisting of words,
so criterion 1 can be applied, except that it's not N-bit, but
N-digit.
Anything else?
BTW, note that these are architectural (i.e., instruction-set-related) criteria; an implementation can implement several instruction sets.
E.g., I can run programs for the 16-bit 8086 architecture, for the
32-bit IA-32 architecture and for the 64-bit AMD64 architecture on,
e.g., the recent AMD Ryzen 9 9950X and the Intel Core Ultra 9 285K.
Everyone agreed that all the models of S/360 were 32 bit machines, but the >>implementations ranged from 8 bits for the /25 and /30 to 64 bits for
the /75.
This sentence is contradictory. All these implementations have 32-bit general-purpose registers (otherwise they would not be S/360 implementations), which are address registers, and are therefore
32-bit architectures by your and my criteria.
You obviously mean something different about these implementations.
What is it?
... and AFAIK the RISC-V V extension ...
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition
for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
To me, the phrase "n-bit architecture" should depend only on such
characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
Thomas Koenig <tkoenig@netcologne.de> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition
for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
To me, the phrase "n-bit architecture" should depend only on such
characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
I expect most of the folks who participate in comp.arch are
aware of the distinction. What I find disappointing are
postings that ignore or blur the distinction, so it's hard
to tell where one domain ends and the other begins.
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition >>>>> for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark
on the latter).
To me, the phrase "n-bit architecture" should depend only on such
characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit
(or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
I expect most of the folks who participate in comp.arch are
aware of the distinction. What I find disappointing are
postings that ignore or blur the distinction, so it's hard
to tell where one domain ends and the other begins.
If you find discussions about how certain times were used
in the past disappointing... [..]
Thomas Koenig <tkoenig@netcologne.de> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
I think "ALU can add up to n-bit numbers" is a reasonable definition >>>>>> for an n-bit architecture, which also fits the 16-bit 68000.
It does not fit the 360/30, or the Nova (but see de Castro's remark >>>>>> on the latter).
To me, the phrase "n-bit architecture" should depend only on such
characteristics as are defined by the architecture, and not depend
on features of a particular implementation. The 360/30 has a 32-bit >>>>> (or is it 64-bit?) architecture, but only an 8-bit implementation.
If I may add a personal note, it's disappointing that postings in a
group nominally devoted to computer architecture routinely ignore
the distinction between architecture and implementation.
I'm well aware of that distinction.
I expect most of the folks who participate in comp.arch are
aware of the distinction. What I find disappointing are
postings that ignore or blur the distinction, so it's hard
to tell where one domain ends and the other begins.
If you find discussions about how certain times were used
in the past disappointing... [..]
That isn't what I said, nor was it what I meant.