I think "ALU can add up to n-bit numbers" is a reasonable definitionOr the CDP1802. 8 bit accumulator and 1 bit ALU.
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).
On 12/1/24 8:03 AM, Thomas Koenig wrote:
I think "ALU can add up to n-bit numbers" is a reasonable definitionOr the CDP1802. 8 bit accumulator and 1 bit ALU.
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).
On Sun, 1 Dec 2024 17:53:19 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:I'm well aware of that distinction.
I think "ALU can add up to n-bit numbers" is a reasonableTo me, the phrase "n-bit architecture" should depend only on such
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).
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.
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.
IMHO, the authors of the book are wrong. At least as long as were are
talking about current meaning of the bitness. It is possible that 40
years ago the word had different meaning. But I find more likely that
it had no established meaning.
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.
RISC-V has the pointer-masking extension, which ignores the top 7 bits
(like AMD's upper-address ignore) or optionally 16 bits.
See <https://muxup.com/2023q4/storing-data-in-pointers> and <https://lwn.net/Articles/902094/>.
Concerning the kernel requirements, as someone who has implemented
Prolog with tagging, having to untag on passing an address to the
kernel would be only a minimal cost. Not having to unmask on every
memory access would be quite useful. Having the top bit always be 0
with the tags in the 6 bits below would not have been a restriction
for us (we used 4-bit tags); OTOH, if one more bit was available,
programmers would find good uses for it.
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? Note that until recently,
Intel sold you the same silicon either with only XMM or with XMM and
YMM registers. They sell consumer CPUs with XMM, YMM, and ZMM
registers, but more recent consumer and small-server CPUs have
reverted to only supporting XMM and YMM registers.
- anton
On 11/29/2024 10:28 PM, Anton Ertl wrote:
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.
Fwiw, stealing bits from pointers is a common practice in exotic
lock-free algorithms. It's not portable at all, but comes in handy!
On Sun, 1 Dec 2024 23:22:14 +0000, Chris M. Thomasson wrote:
On 11/29/2024 10:28 PM, Anton Ertl wrote:
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.
Fwiw, stealing bits from pointers is a common practice in exotic
lock-free algorithms. It's not portable at all, but comes in handy!
How are you going to write these algorithms when a pointer consumes
all 64-bits of the register/memory container ?? VAS = 64-bits.
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 don't
mind comments about matters of implementation, but the constant
blurring (or erasing) of the line between architecture and
implementation often makes it nearly impossible to have a discussion
just about architecture.
On 12/1/2024 5:26 PM, MitchAlsup1 wrote:
On Sun, 1 Dec 2024 23:22:14 +0000, Chris M. Thomasson wrote:
On 11/29/2024 10:28 PM, Anton Ertl wrote:
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.
Fwiw, stealing bits from pointers is a common practice in exotic
lock-free algorithms. It's not portable at all, but comes in handy!
How are you going to write these algorithms when a pointer consumes
all 64-bits of the register/memory container ?? VAS = 64-bits.
You don't for they are not portable at all. However, on systems were we
can steal some bits of a pointer value in C/C++, well, we can do it and create some interesting algorithms.
another way to steal bits is over alignment.
another way to steal bits is over alignment.
Yup. I keep lamenting that Alpha didn't go for bit-addressed memory,
which would have given us 3 extra free bits from alignment (as well as >allowing pointers to bits and bitfields).
I thought STRETCH persuaded people that bit addressable memory was a bad idea.another way to steal bits is over alignment.Yup. I keep lamenting that Alpha didn't go for bit-addressed memory,
which would have given us 3 extra free bits from alignment (as well as >>allowing pointers to bits and bitfields).
According to Stefan Monnier <monnier@iro.umontreal.ca>:
another way to steal bits is over alignment.
Yup. I keep lamenting that Alpha didn't go for bit-addressed memory,
which would have given us 3 extra free bits from alignment (as well as >>allowing pointers to bits and bitfields).
I thought STRETCH persuaded people that bit addressable memory was a bad idea.
I thought STRETCH persuaded people that bit addressable memory was a bad idea.another way to steal bits is over alignment.Yup. I keep lamenting that Alpha didn't go for bit-addressed memory, >>>which would have given us 3 extra free bits from alignment (as well as >>>allowing pointers to bits and bitfields).
Yes, but that was a misunderstanding. I'm not suggesting that
load/store instructions can access things at any bit position and any
bit size. Any load or store with a pointer whose last 3 bits is not 0 would >presumably signal en error.
Just like the 21064 Alpha where they had byte-addressed memory but the >load/store instructions could only handle aligned words.
Yes, but that was a misunderstanding. I'm not suggesting thatSeems like an odd place to put what are in practice just flag bits.
load/store instructions can access things at any bit position and any
bit size. Any load or store with a pointer whose last 3 bits is not 0 would >>presumably signal en error.
Just like the 21064 Alpha where they had byte-addressed memory but the >>load/store instructions could only handle aligned words.Well, we know how that turned out, not unlike the way IBM designed the 360
to require data alignment, got badly bitten when they realized it broke a
lot of Fortran programs, and added unaligned accesses in the 360/85.
another way to steal bits is over alignment.
Yup. I keep lamenting that Alpha didn't go for bit-addressed memory,
which would have given us 3 extra free bits from alignment (as well as allowing pointers to bits and bitfields).
On Tue, 3 Dec 2024 18:19:51 +0000, John Levine wrote:
According to Stefan Monnier <monnier@iro.umontreal.ca>:
another way to steal bits is over alignment.
Yup. I keep lamenting that Alpha didn't go for bit-addressed memory,
which would have given us 3 extra free bits from alignment (as well as
allowing pointers to bits and bitfields).
I thought STRETCH persuaded people that bit addressable memory was a bad
idea.
With the address space STRETCH had bit addressability IS a VERY bad
Idea.
We now have people (again) using the top bits of pointers for "special things".
Thus the Ferris wheel of invention is caught in a loop.
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.
David Schultz <david.schultz@earthlink.net> schrieb:
On 12/1/24 8:03 AM, Thomas Koenig wrote:
I think "ALU can add up to n-bit numbers" is a reasonable definitionOr the CDP1802. 8 bit accumulator and 1 bit ALU.
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).
Or the PDP-8/S...
Yes, but that was a misunderstanding. I'm not suggesting thatSeems like an odd place to put what are in practice just flag bits.
load/store instructions can access things at any bit position and any
bit size. Any load or store with a pointer whose last 3 bits is not 0
would
presumably signal en error.
It's a very natural one, tho. Byte addressing is somewhat arbitrary
(why 8 bits, why not 16 or 4 or 6 or 9 ...?), whereas bit-addressing has
some logic to it (fractional bit addressing would be hard to define).
Just like the 21064 Alpha where they had byte-addressed memory but the >>>load/store instructions could only handle aligned words.Well, we know how that turned out, not unlike the way IBM designed the
360
to require data alignment, got badly bitten when they realized it broke
a
lot of Fortran programs, and added unaligned accesses in the 360/85.
Yes, but contrary to the case for bytes, there is virtually (literally?)
no code out there which expects non-byte-aligned memory accesses
to work.
It would suffer from some incompatibilities, of course, since +1 on
a `char*` would correspond to +8 on the underlying integer, so I'd
expect most `malloc` libraries to croak along with various other
non-100% portable code, but what's a few incompatibility between
friends, when you consider the fact that your architecture would be philosophically cleaner, able to point to bit fields, *and* grant
3 extra tag bits to implementors of dynamically typed languages?
Stefan--- Synchronet 3.20a-Linux NewsLink 1.114
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[...]
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.
One example of this that I haven't seen mentioned here is used by the C
and C++ compilers for Cray vector machines (I've used the T90 and SV1).
These systems had a 64-bit word size, and were heavily optimized
for floating-point operations. Hardware addresses referred to 64-bit
words. Compatibility with other systems required support for 8-bit
bytes (CHAR_BIT==8). This was implemented in generated code by using
the high-order 3 bits of an address as a byte offset.
The fact that all byte addressing was implemented in software meant
that, for example, string manipulation was remarkably slow -- but it
worked.
(I'm using the past tense because I don't know whether any of these--- Synchronet 3.20a-Linux NewsLink 1.114
systems are still in use.)
Or the CDP1802. 8 bit accumulator and 1 bit ALU.
Or the PDP-8/S...
We who used a PDP-8S considered it a (slow) 12-bit machine.
FORTRAN COMMON blocks require misaligned accesses to double precision
data.
R E Q U I R E in that it is neither optional nor wise to emulate with exceptions. It is just barely tolerable using LD/ST Left/Right
instructions
out of the compiler.
Yes, but contrary to the case for bytes, there is virtually (literally?)FORTRAN COMMON blocks require misaligned accesses to double precision
no code out there which expects non-byte-aligned memory accesses
to work.
data.
Never deference a pointer with stolen bits!!!!!!!!!!!!!!!!!!
Fair enough?
On Tue, 3 Dec 2024 23:52:10 +0000, Stefan Monnier wrote:
Yes, but that was a misunderstanding. I'm not suggesting that >>>>load/store instructions can access things at any bit position and any >>>>bit size. Any load or store with a pointer whose last 3 bits is not 0Seems like an odd place to put what are in practice just flag bits.
would
presumably signal en error.
It's a very natural one, tho. Byte addressing is somewhat arbitrary
(why 8 bits, why not 16 or 4 or 6 or 9 ...?), whereas bit-addressing has
some logic to it (fractional bit addressing would be hard to define).
Various architectures used 6-bit characters--you get 64 characters which
is good enough for the 16 letters, 10 digits, and all the pnctuation >+-*/&|^(){}[]_ ... Realistically, you do not need 7-bit characters until
you add lower case. AND there are some situations where 9-bit characters >would be superior to 8-bit ones.
8-bits won because it was enough (at the time of inception {IBM
360--1963})
Yes, but contrary to the case for bytes, there is virtually (literally?) >>> no code out there which expects non-byte-aligned memory accessesFORTRAN COMMON blocks require misaligned accesses to double precision
to work.
data.
I don't think FORTRAN stipulate this also applies to sub-byte alignment.
Stefan--- Synchronet 3.20a-Linux NewsLink 1.114
Yes, but contrary to the case for bytes, there is virtually (literally?) >>> no code out there which expects non-byte-aligned memory accessesFORTRAN COMMON blocks require misaligned accesses to double precision
to work.
data.
I don't think FORTRAN stipulate this also applies to sub-byte alignment.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 997 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 57:07:19 |
| Calls: | 13,035 |
| Calls today: | 2 |
| Files: | 186,574 |
| Messages: | 3,287,313 |