| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 104:13:35 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,612 |
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.
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!
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.
another way to steal bits is over alignment.
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).
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.
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
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...
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
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
Tim Rentsch wrote:
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.
I agree!
The one exception which I personally find OK are discussions of what
happens when an implementation is so bad that it effectively removes
the architecture feature from programmer consideration.
I.e. having architectural string/memcpy instructions that are much
slower than sw implementations, for several decades.