Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #110102 > unrolled thread

What is an N-bit machine?

Back to article view | Back to comp.arch

Contents

  What is an N-bit machine? jgd@cix.co.uk (John Dallman) - 2024-11-28 15:31 +0000
    Re: What is an N-bit machine? scott@slp53.sl.home (Scott Lurndal) - 2024-11-28 16:33 +0000
    Re: What is an N-bit machine? Michael S <already5chosen@yahoo.com> - 2024-11-28 18:55 +0200
      Re: What is an N-bit machine? John Levine <johnl@taugh.com> - 2024-11-30 02:37 +0000
        Re: What is an N-bit machine? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-11-29 22:30 -0800
          Re: What is an N-bit machine? John Levine <johnl@taugh.com> - 2024-11-30 19:40 +0000
            Re: What is an N-bit machine? Michael S <already5chosen@yahoo.com> - 2024-11-30 22:38 +0200
              Re: What is an N-bit machine? "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-12-01 11:23 -0500
                Re: What is an N-bit machine? scott@slp53.sl.home (Scott Lurndal) - 2024-12-01 19:52 +0000
            Re: What is an N-bit machine? mitchalsup@aol.com (MitchAlsup1) - 2024-11-30 22:39 +0000
              Re: What is an N-bit machine? Thomas Koenig <tkoenig@netcologne.de> - 2024-12-01 08:19 +0000
                Re: What is an N-bit machine? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-01 08:35 +0000
              Re: What is an N-bit machine? Terje Mathisen <terje.mathisen@tmsw.no> - 2024-12-02 09:48 +0100
                Re: What is an N-bit machine? "Brian G. Lucas" <bagel99@gmail.com> - 2024-12-02 19:56 -0500
                  Re: What is an N-bit machine? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-12-03 00:01 -0800
                Re: What is an N-bit machine? antispam@fricas.org (Waldek Hebisch) - 2024-12-15 18:20 +0000
        Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-30 06:28 +0000
          Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-30 11:35 +0000
            Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2024-11-30 11:58 +0000
              Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-30 16:57 +0000
                Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Michael S <already5chosen@yahoo.com> - 2024-11-30 19:32 +0200
                  Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-30 18:08 +0000
                    Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Michael S <already5chosen@yahoo.com> - 2024-11-30 20:28 +0200
                      Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-01 09:28 +0000
                        Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2024-12-01 14:03 +0000
                          Re: Keeping other stuff with addresses David Schultz <david.schultz@earthlink.net> - 2024-12-01 08:15 -0600
                            Re: Keeping other stuff with addresses Thomas Koenig <tkoenig@netcologne.de> - 2024-12-01 14:40 +0000
                              Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-04 02:19 +0000
                                Re: Keeping other stuff with addresses John Levine <johnl@taugh.com> - 2024-12-04 03:25 +0000
                          Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 07:32 -0800
                            Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2024-12-01 17:53 +0000
                              Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Michael S <already5chosen@yahoo.com> - 2024-12-01 20:05 +0200
                                Re: Keeping other stuff with addresses EricP <ThatWouldBeTelling@thevillage.com> - 2024-12-01 18:16 -0500
                              Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Brett <ggtgp@yahoo.com> - 2024-12-01 20:02 +0000
                              Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-31 08:54 -0800
                                Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-01 15:28 +0000
                                  Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-01 17:39 -0800
                                    Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-02 09:59 +0000
                                      Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-08 10:00 -0800
                                        Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-08 19:18 +0000
                                          Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:05 -0800
                                            Re: Keeping other stuff with addresses David Brown <david.brown@hesbynett.no> - 2025-01-28 08:30 +0100
                                              Re: Keeping other stuff with addresses Thomas Koenig <tkoenig@netcologne.de> - 2025-02-02 08:37 +0000
                            Re: Keeping other stuff with addresses Terje Mathisen <terje.mathisen@tmsw.no> - 2024-12-02 17:10 +0100
                              Re: Keeping other stuff with addresses Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-31 08:46 -0800
                    Re: Keeping other stuff with addresses (was: What is an N-bit machine?) John Levine <johnl@taugh.com> - 2024-11-30 19:12 +0000
                      What is an N-bit machine? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-01 08:41 +0000
                        Re: What is an N-bit machine? scott@slp53.sl.home (Scott Lurndal) - 2024-12-01 15:52 +0000
                        Re: What is an N-bit machine? antispam@fricas.org (Waldek Hebisch) - 2024-12-16 22:39 +0000
                    Re: Keeping other stuff with addresses (was: What is an N-bit machine?) Thomas Koenig <tkoenig@netcologne.de> - 2024-11-30 22:06 +0000
                      Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-01 08:38 +0000
          Re: Keeping other stuff with addresses (was: What is an N-bit machine?) scott@slp53.sl.home (Scott Lurndal) - 2024-11-30 17:57 +0000
            Re: Keeping other stuff with addresses (was: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-01 09:38 +0000
          Re: Keeping other stuff with addresses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 15:22 -0800
            Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-02 01:26 +0000
              Re: Keeping other stuff with addresses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 20:12 -0800
                Re: Keeping other stuff with addresses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-02 16:54 -0800
                  Re: Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-03 11:51 -0500
                    Re: Keeping other stuff with addresses John Levine <johnl@taugh.com> - 2024-12-03 18:19 +0000
                      Re: Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-03 13:46 -0500
                        Re: Keeping other stuff with addresses John Levine <johnl@taugh.com> - 2024-12-03 23:33 +0000
                          Re: Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-03 18:52 -0500
                            Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-04 02:36 +0000
                              Re: Keeping other stuff with addresses Thomas Koenig <tkoenig@netcologne.de> - 2024-12-04 06:29 +0000
                              Re: Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-04 10:32 -0500
                                Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-04 19:47 +0000
                                Re: Keeping other stuff with addresses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-04 15:47 -0800
                              Re: Keeping other stuff with addresses scott@slp53.sl.home (Scott Lurndal) - 2024-12-04 16:31 +0000
                                Re: bytes, Keeping other stuff with addresses John Levine <johnl@taugh.com> - 2024-12-05 00:39 +0000
                              unaligned load/store (was: Re: Keeping other stuff with addresses) Jonathan Thornburg <jonathan@gold.bkis-orchard.net> - 2024-12-21 23:22 +0000
                                Re: unaligned load/store mitchalsup@aol.com (MitchAlsup1) - 2024-12-22 01:27 +0000
                                  Re: unaligned load/store Thomas Koenig <tkoenig@netcologne.de> - 2024-12-22 10:01 +0000
                                    Re: unaligned load/store anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-22 11:06 +0000
                                    Re: unaligned load/store jgd@cix.co.uk (John Dallman) - 2024-12-22 11:42 +0000
                                    Re: unaligned load/store "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-22 19:41 -0800
                                  Re: unaligned load/store Thomas Koenig <tkoenig@netcologne.de> - 2024-12-22 21:04 +0000
                                    Re: unaligned load/store mitchalsup@aol.com (MitchAlsup1) - 2024-12-22 23:32 +0000
                                    Re: unaligned load/store Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-26 13:38 -0500
                                      Re: unaligned load/store George Neuner <gneuner2@comcast.net> - 2024-12-26 16:31 -0500
                                      Re: unaligned load/store mitchalsup@aol.com (MitchAlsup1) - 2024-12-26 21:59 +0000
                                        Re: unaligned load/store "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-26 14:05 -0800
                                Re: unaligned load/store (was: Re: Keeping other stuff with addresses) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-12-22 10:33 +0000
                            Re: bits and bytes, Keeping other stuff with addresses John Levine <johnl@taugh.com> - 2024-12-04 03:39 +0000
                              Re: bits and bytes, Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-04 10:36 -0500
                      Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-03 19:22 +0000
                        Re: Keeping other stuff with addresses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-03 17:03 -0800
                    Re: Keeping other stuff with addresses "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-03 16:56 -0800
                      Re: Keeping other stuff with addresses Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-04 10:37 -0500
          Re: Keeping other stuff with addresses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-03 17:43 -0800
            Re: Keeping other stuff with addresses mitchalsup@aol.com (MitchAlsup1) - 2024-12-04 02:42 +0000
    Re: What is an N-bit machine? Thomas Koenig <tkoenig@netcologne.de> - 2024-11-28 17:56 +0000
      Re: What is an N-bit machine? mitchalsup@aol.com (MitchAlsup1) - 2024-11-28 19:02 +0000
        Re: What is an N-bit machine? Brett <ggtgp@yahoo.com> - 2024-11-28 19:39 +0000
      Re: What is an N-bit machine? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-28 21:42 +0000
        Re: What is an N-bit machine? jgd@cix.co.uk (John Dallman) - 2024-11-28 22:08 +0000
          Re: What is an N-bit machine? Lynn Wheeler <lynn@garlic.com> - 2024-11-28 12:44 -1000
            Re: What is an N-bit machine? jgd@cix.co.uk (John Dallman) - 2024-11-28 22:58 +0000
            IBM and Amdahl history (Re: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-29 07:22 +0000
              Re: IBM and Amdahl history (Re: What is an N-bit machine?) Lynn Wheeler <lynn@garlic.com> - 2024-11-29 08:24 -1000
              Re: IBM and Amdahl history (Re: What is an N-bit machine?) scott@slp53.sl.home (Scott Lurndal) - 2024-11-29 18:29 +0000
              Re: IBM and Amdahl history (Re: What is an N-bit machine?) Lynn Wheeler <lynn@garlic.com> - 2024-11-29 11:51 -1000
              Re: IBM and Amdahl history (Re: What is an N-bit machine?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-29 21:51 +0000
                Re: IBM and Amdahl history (Re: What is an N-bit machine?) scott@slp53.sl.home (Scott Lurndal) - 2024-11-30 17:45 +0000
                  Re: IBM and Amdahl history (Re: What is an N-bit machine?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-30 18:19 +0000
                    Re: IBM and Amdahl history (Re: What is an N-bit machine?) jgd@cix.co.uk (John Dallman) - 2024-11-30 22:19 +0000
                    Re: IBM and Amdahl history (Re: What is an N-bit machine?) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-30 23:21 +0000
          Re: What is an N-bit machine? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-29 02:17 +0000
            Re: What is an N-bit machine? Brett <ggtgp@yahoo.com> - 2024-11-30 01:29 +0000
            Re: market power, What is an N-bit machine? John Levine <johnl@taugh.com> - 2024-11-30 02:42 +0000
            Re: What is an N-bit machine? Lynn Wheeler <lynn@garlic.com> - 2024-11-29 17:42 -1000
    Re: What is an N-bit machine? mitchalsup@aol.com (MitchAlsup1) - 2024-11-28 19:01 +0000
    Re: What is an N-bit machine? Lynn Wheeler <lynn@garlic.com> - 2024-11-28 11:45 -1000
    Re: What is an N-bit machine? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-11-29 08:03 +0000
      Re: What is an N-bit machine? Thomas Koenig <tkoenig@netcologne.de> - 2024-11-29 19:17 +0000
      Re: What is an N-bit machine? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-22 21:37 +0000

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#110181 — Re: Keeping other stuff with addresses

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

Seems like an odd place to put what are in practice just flag bits.

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

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#110183 — Re: Keeping other stuff with addresses

>>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.
> Seems like an odd place to put what are in practice just flag bits.

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

[toc] | [prev] | [next] | [standalone]

#110192 — Re: Keeping other stuff with addresses

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 0
>>> would
>>>presumably signal en error.
>> Seems like an odd place to put what are in practice just flag bits.
>
> 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})
we had no need for larger character sets. That need did not arise until
word processors were created (late 1980s) and by then 8-bit characters
were standard.

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

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.

I, personally, went through enough PAIN with misalignment, that over
time my mood swung from "aligned only" to "completely misaligned"::
a) because there is no performant* SW workaround
b) it is SO easy to fix in HW.
c) once fixed in HW, any SW burden is so small as to be barely
..measurable.

(*) MIPS LD/ST left/right still requires SW to be aware of the
misalignment so the compiler can emit enough instructions. How
much easier is it if the compiler remains blissfully unaware of
any misalignment.

> 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

[toc] | [prev] | [next] | [standalone]

#110197 — Re: Keeping other stuff with addresses

MitchAlsup1 <mitchalsup@aol.com> schrieb:

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

This option is violated by all compilers that I currently have
access to, and is also incompatible with, for exmaple, the x86_64
ABI on Linux (which requires alignment as if for C structs).

For gfortran, you need a special flag to enforce it.

[toc] | [prev] | [next] | [standalone]

#110199 — Re: Keeping other stuff with addresses

>> 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.
> FORTRAN COMMON blocks require misaligned accesses to double precision
> data.

I don't think FORTRAN stipulate this also applies to sub-byte alignment.


        Stefan

[toc] | [prev] | [next] | [standalone]

#110208 — Re: Keeping other stuff with addresses

On Wed, 4 Dec 2024 15:32:58 +0000, Stefan Monnier wrote:

>>> 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.
>> FORTRAN COMMON blocks require misaligned accesses to double precision
>> data.
>
> I don't think FORTRAN stipulate this also applies to sub-byte alignment.

FORTRAN (of that era) only had words and then went on to describe
double precision FP to take 2 of those words without specifying
any additional alignment criteria.

Later Fortrans (from FORTRAN 77, WATfor, and WATfiv) we have Character*1
>
>
>         Stefan

[toc] | [prev] | [next] | [standalone]

#110209 — Re: Keeping other stuff with addresses

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 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.
>> FORTRAN COMMON blocks require misaligned accesses to double precision
>> data.
>
> I don't think FORTRAN stipulate this also applies to sub-byte alignment.

I see that you use Gnus, the same newsreader I use.

When you post a followup, Gnus automatically adds attribution lines,
like the "Stefan Monnier <monnier@iro.umontreal.ca> writes:" line in
this post.  Please leave those lines in place.  It makes it easier to
follow conversations.  (Yes, readers can typically jump to the parent
article, but it's not always easy to do that or to get back to the
current article.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#110203 — Re: Keeping other stuff with addresses

mitchalsup@aol.com (MitchAlsup1) writes:
>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 0
>>>> would
>>>>presumably signal en error.
>>> Seems like an odd place to put what are in practice just flag bits.
>>
>> 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})

8-bits is also a convenient multiple of four bits, which was common
in many machines prior to the 360.  The hardware in burroughs
BCD machines could automatically add/remove the zone digit (bits <7:4>)
during data movement.

[toc] | [prev] | [next] | [standalone]

#110210 — Re: bytes, Keeping other stuff with addresses

According to Scott Lurndal <slp53@pacbell.net>:
>>8-bits won because it was enough (at the time of inception {IBM
>>360--1963})
>
>8-bits is also a convenient multiple of four bits, which was common
>in many machines prior to the 360.  The hardware in burroughs
>BCD machines could automatically add/remove the zone digit (bits <7:4>)
>during data movement.

Good point.  S/360 packed decimal puts two digits in each byte with the low
"digit" of the low order byte being the sign.  If they had six bit bytes, the
only other size they seriously considered, they'd either waste 1/3 of the
bits with a digit per byte, or need what would then have been an impossibly
complex encoding.

Several decades later, decimal floating point used such a complex encoding.




-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#110290 — unaligned load/store (was: Re: Keeping other stuff with addresses)

MitchAlsup1 <mitchalsup@aol.com> wrote:
> 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.
> 
> I, personally, went through enough PAIN with misalignment, that over
> time my mood swung from "aligned only" to "completely misaligned"::
> a) because there is no performant* SW workaround
> b) it is SO easy to fix in HW.
> c) once fixed in HW, any SW burden is so small as to be barely
> ..measurable.

I'm not so sure (b) is true.  Some cases are moderately easy to handle
in hardware (e.g., misaligned loads that stay within a single L1 D-cache
line), but some cases are harder (e.g., misaligned writes that cross L1
D-cache line boundaries) and might need a microcode trap (awkward if the
design wasn't otherwise using microcode).  And some cases are even harder
(e.g., misaligned writes crossing L1 D-cache line boundaries where the
two lines are owned by different CPUs in a cache-coherent multiprocessor)
and might need a millicode trap.  And some cases may require going all the
way up to the OS (e.g., misaligned writes that cross virtual-memory-page
boundaries where one page is ok but the other is non-resident).

So, allowing this in the architecture has several costs:
* extra hardware implementation effort to make sure the "hardware" cases
  don't cost an extra gate delay or two on some critical path
* extra complexity and debugging time in hardware and in system software
  (think about writing and *debugging* and *verifying* microcode/millicode
  trap handlers for all those messy write-crossing-cache/page-boundary
  cases, especially their interactions with multiprocessor cache coherency)
* this extra effort means a longer design time and/or greater design cost,
  and hence (so long as the state-of-the-art of competing systems is still
  steadily improving with time) that means a net lower price/performance
  relative to competing systems

And, because of the traps and their overheads (which will likely differ
significantly across different implementations of the same architecture,
e.g., different multiprocessor cache-coherency protocols), any code that
actually *uses* unaligned accesses -- especially unaligned writes -- isn't
performance-portable unless the actual dynamic frequency of unaligned
operations is very low.

So yes, allowing unaligned access does help "dusty deck" Fortran code...
but it comes at a significant cost.

-- 
-- "Jonathan Thornburg [remove -color to reply]" <jt.bhbkis@gmail-pink.com>
   on the west coast of Canada
   "the stock market can remain irrational a lot longer than you can
   remain solvent" or (probably the correct original wording) "markets
   can remain irrational a lot longer than you and I can remain solvent"
         -- A. Gary Shilling (often misattributed to John Maynard Keynes)

[toc] | [prev] | [next] | [standalone]

#110291 — Re: unaligned load/store

On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:

> MitchAlsup1 <mitchalsup@aol.com> wrote:
>> 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.
>>
>> I, personally, went through enough PAIN with misalignment, that over
>> time my mood swung from "aligned only" to "completely misaligned"::
>> a) because there is no performant* SW workaround
>> b) it is SO easy to fix in HW.
>> c) once fixed in HW, any SW burden is so small as to be barely
>> ..measurable.
>
> I'm not so sure (b) is true.  Some cases are moderately easy to handle
> in hardware (e.g., misaligned loads that stay within a single L1 D-cache
> line), but some cases are harder (e.g., misaligned writes that cross L1
> D-cache line boundaries) and might need a microcode trap (awkward if the
> design wasn't otherwise using microcode).  And some cases are even
> harder

While there is no concept of Millicode or Microcode::
There are several sequencing components::

a) determining if the access is misaligned:: This takes 8 gates and 2
gates
of delay from an adder already comprising 2000 gates. The misaligned
assertion
comes 5-6 gates BEFORE the higher order 32-bits come out of the adder::
I consider this part ignorable.
b) accessing the cache optimally in the presence of misaligned accesses.
b.1) if the access does not cross a cache port boundary, then all the
problems are confined to the alignment of the data.
b.2) if the access crosses a port boundary but not a line boundary,
access 2 successive ports, and allow Aligner to sort out the problem.
b.3) if the access crosses a line boundary but not a page boundary,
access 2 successive ports incrementing the line address of the second
port.
b.4) if the access crosses a page boundary, you are going to have to
access the cache twice, once for the first page, once for the second.

So, only page crossing REQUIRES 2 accesses; and 99% (Made up number)
are performed in a single cycle. {{Try that with some kind of SW
workaround}}

{{Oh, and BTW; this is a good place to check that the access rights
to both pages are compatible with the rights in both PTEs.}}

So,
AGEN adder is 8 gates bigger out of 2,000 total gates
Cache port control logic is 2× as big out of 90 gates
Cache staging flip-flops in stage ALIGN is 2× as big
LD Aligner is bigger ~1.75×
Tag, TLB, DATA RAMs are exactly the same size and ~9× larger
....than of the other cache pipeline logic area
{{And you add 25-odd gates in the Miss Buffers}}

x86 has been doing this for 3 decades. It is well worn logic at this
point.
It was at AMD where I saw how easy this was for HW to simply "make the
problem disappear" compared to all the ways SW uses to work around "not
being able to access misaligned data". Once you have done it once, you
have the logic and test vectors to insure you don't shoot yourself in
the foot.

Any competent programmer will ALIGN his data to the extend possible
there is no reason to penalize {Compiler, assembler, linker, ld.so,...}
just because you want to take 5 days out of design.

So, My design:
Aligned data is always best, Misaligned data comes at very low cost.
SW overhead = 0

Your design:
Aligned data works just fine, Misaligned data is a complete nightmare
throughout the entire SW stack, and causes large uncertainty in result
deliver time. SW overhead = significant.

How many days of SW development are required to make up for the 5 days
of HW design to simply eradicate the problem.

You would not buy a car without anti-lock brakes--even though you will
only use the feature once or twice in your ownership of the vehicle !?!
Why would you buy a CPU that is not similar?

> (e.g., misaligned writes crossing L1 D-cache line boundaries where the
> two lines are owned by different CPUs in a cache-coherent
> multiprocessor)
> and might need a millicode trap.  And some cases may require going all
> the
> way up to the OS (e.g., misaligned writes that cross virtual-memory-page
> boundaries where one page is ok but the other is non-resident).

Millicode is so DEC ALPHA. Fixing the problem in HW does not require
anything but the 5 sequences I illustrated above--this amount of
sequencers are invisible in the cache pipeline as a whole.

> So, allowing this in the architecture has several costs:
> * extra hardware implementation effort to make sure the "hardware" cases
>   don't cost an extra gate delay or two on some critical path

AMD had done all of this by 1997. {don't know about when Intel had it
licked}

But, yes, if you have a balls-to-the-wall pipeline (R2000) adding a gate
of
delay would degrade performance by ~5%. This has only been shown to be
an
issue when the cache pipeline is 2 stages and one is trying to get::

     Forward->AGEN->RAMS->ALIGN->resultbus in 2 cycles.

MIPS had to use direct mapped caches to meet this timing, and had to
sample SRAM chips on its own test head to measure if the SRAMs had
pin timings appropriate to R2000 timings.

Once you have set-associativity or allow for 3 cycles {note current
Intel cores are using 5 cycles.} your argument fails.

While your argument might succeed in 2µ-through-90nm, wires have become
so slow that in many cases adding a gat of pure delay does not slow
anything because the cache pipeline has been engineered O F F the/any
critical path. So, while RISC-V persists with the 2 cycle cache pipe-
line, the big boys have migrated to longer pipelines and build execution
windows to absorb the added latencies.

> * extra complexity and debugging time in hardware and in system software
>   (think about writing and *debugging* and *verifying*
> microcode/millicode
>   trap handlers for all those messy write-crossing-cache/page-boundary
>   cases, especially their interactions with multiprocessor cache
> coherency)

There is N O   M I L L I C O D E. There is a sequencer that can take 1
of
5 paths over the AGEN-CACHE-ALIGN stages of the pipeline. SW has to do
nothing to enable this, or overcome poor/bad use of ISA.

> * this extra effort means a longer design time and/or greater design
> cost,
>   and hence (so long as the state-of-the-art of competing systems is
> still
>   steadily improving with time) that means a net lower price/performance
>   relative to competing systems

So does IEEE 754 floating point !! It is significantly more logic
intensive
than IBM or CRAY or Univac floating points. Yet, currently, some larger
cores contain 4-8 of these floating point units (8-16 is you separate
FMUL/FDIV from FADD/FSUB/FCMP).

> And, because of the traps

There are N O   T R A P S, no exceptions (other than expected), no
interrupt dependencies, no mispredict repair dependencies, no
coherence dependencies, ...

>                           and their overheads (which will likely differ
> significantly across different implementations of the same architecture,
> e.g., different multiprocessor cache-coherency protocols), any code that
> actually *uses* unaligned accesses -- especially unaligned writes --
> isn't
> performance-portable unless the actual dynamic frequency of unaligned
> operations is very low.

UnTrue.

> So yes, allowing unaligned access does help "dusty deck" Fortran code...
> but it comes at a significant cost.

Less than 0.1% is a significant cost ?!?!?

[toc] | [prev] | [next] | [standalone]

#110292 — Re: unaligned load/store

MitchAlsup1 <mitchalsup@aol.com> schrieb:
> On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:

> Any competent programmer will ALIGN his data to the extend possible
> there is no reason to penalize {Compiler, assembler, linker, ld.so,...}
> just because you want to take 5 days out of design.

These days, the competence of many programmers can be called into
question :-)

ABIs, however, generally require natural alignment for types, so
the point is somehwat moot, at least where user code is concerned.
Consider

typedef struct
{
  unsigned char a;
  unsigned long b;
} mytype;

unsigned long add (mytype *x)
{
  return x->a + x->b;
}

which gets translated into

        ldub    r2,[r1]
        ldd     r1,[r1,8]
        add     r1,r1,r2
        ret

so the cost for the tool chain is already spent (or is spent
again and again if people use structs like the above).  I think
the VAX was the last major architecture which specified unaligned
struct access.

> On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:

>> So yes, allowing unaligned access does help "dusty deck" Fortran code...
>> but it comes at a significant cost.

Fortran compilers, even on machines which allow misalignment, use
ABIs which specify alignment for COMMON blocks, in violation of
the Fortran standard.  They usually have a flag for when the
user actually needs to have no padding.

Code which which would not work with padding would have to be dusty
indeed (fossilized?) if it used COMMON blocks that way.  It would
never have run on early RISCs, so it would likely have had a time
of non-use in the 1990s when RISCs ruled in price/performance
after mainframes and the VAX fell behind.

[toc] | [prev] | [next] | [standalone]

#110294 — Re: unaligned load/store

Thomas Koenig <tkoenig@netcologne.de> writes:
>ABIs, however, generally require natural alignment for types, so
>the point is somehwat moot, at least where user code is concerned.

Let's weaken this to "good ABIs require natural alignment for basic
types".  Intel has erred in both directions:

* In its IA32 ABI, they required 4-byte alignment for 8-byte FP data,
  while their hardware traps (with the AC flag set) when accessing an
  8-byte FP value on a 4-byte-aligned address that is not
  8-byte-aligned.  This makes the AC flag useless.

* They made SSE/SSE2 instructions require 16-byte alignment
  irrespective of the basic data type; as a result, at leas one AMD64
  ABI requires 16-byte alignment of the stack on call boundaries,
  which means that many functions have to adjust the stack pointer in
  order to reach that alignment (the CALL instruction changes the
  stack pointer by 8).  That's apparently based on the theory that
  using load and op and movdqa is faster than movdqu, which is
  questionable <https://www.complang.tuwien.ac.at/anton/autovectors/>.

>I think
>the VAX was the last major architecture which specified unaligned
>struct access.

The 4-byte alignment for 8-byte floats on IA-32 also holds for struct
fields.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#110295 — Re: unaligned load/store

In article <vk8o2c$in5m$1@dont-email.me>, tkoenig@netcologne.de (Thomas
Koenig) wrote:

> These days, the competence of many programmers can be called into
> question :-)
> 
> ABIs, however, generally require natural alignment for types, so
> the point is somewhat moot, at least where user code is concerned.
> Consider

Decades ago, there seems to have been a fashion among Windows application
programmers for using somewhat tighter packing. For reasons that I still
don't really understand, Microsoft's x86 C/C++ compiler provides an
option for setting the largest alignment allowed. If you set it to two
bytes, shorts still get natural alignment, but everything larger is
aligned to two-byte boundaries. 

After we'd explained to the third customer that this would not work with
our libraries, it got a paragraph in the documentation, explicitly saying
that it you used it, the libraries would crash. No attempts to do this
have reached second-line support since then. Sometimes, a totally
unvarnished warning is the right thing to use. 

John 

[toc] | [prev] | [next] | [standalone]

#110299 — Re: unaligned load/store

On 12/22/2024 2:01 AM, Thomas Koenig wrote:
> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>> On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:
> 
>> Any competent programmer will ALIGN his data to the extend possible
>> there is no reason to penalize {Compiler, assembler, linker, ld.so,...}
>> just because you want to take 5 days out of design.
> 
> These days, the competence of many programmers can be called into
> question :-)
> 
> ABIs, however, generally require natural alignment for types, so
> the point is somehwat moot, at least where user code is concerned.
> Consider
> 
> typedef struct
> {
>    unsigned char a;
>    unsigned long b;
> } mytype;
> 
> unsigned long add (mytype *x)
> {
>    return x->a + x->b;
> }
> 
> which gets translated into
> 
>          ldub    r2,[r1]
>          ldd     r1,[r1,8]
>          add     r1,r1,r2
>          ret
> 
> so the cost for the tool chain is already spent (or is spent
> again and again if people use structs like the above).  I think
> the VAX was the last major architecture which specified unaligned
> struct access.
> 
>> On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:
> 
>>> So yes, allowing unaligned access does help "dusty deck" Fortran code...
>>> but it comes at a significant cost.
> 
> Fortran compilers, even on machines which allow misalignment, use
> ABIs which specify alignment for COMMON blocks, in violation of
> the Fortran standard.  They usually have a flag for when the
> user actually needs to have no padding.
> 
> Code which which would not work with padding would have to be dusty
> indeed (fossilized?) if it used COMMON blocks that way.  It would
> never have run on early RISCs, so it would likely have had a time
> of non-use in the 1990s when RISCs ruled in price/performance
> after mainframes and the VAX fell behind.

One point, using unaligned access on an x86 with a LOCK prefixed 
instruction will trigger a bus lock. Think of a word that straddles two 
l2 cache lines.

[toc] | [prev] | [next] | [standalone]

#110296 — Re: unaligned load/store

MitchAlsup1 <mitchalsup@aol.com> schrieb:

> Aligned data is always best, Misaligned data comes at very low cost.
> SW overhead = 0

Thinking about this for a bit... for a clean-sheet architecture
like My66000, could there actually be an advantage to do
struct layout like the VAX did, with everything aligned on byte
boundaries?  On the plus side, there would be lower memory use.
On the minus side... very low cost, as you wrote above.

[toc] | [prev] | [next] | [standalone]

#110298 — Re: unaligned load/store

On Sun, 22 Dec 2024 21:04:06 +0000, Thomas Koenig wrote:

> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>
>> Aligned data is always best, Misaligned data comes at very low cost.
>> SW overhead = 0
>
> Thinking about this for a bit... for a clean-sheet architecture
> like My66000, could there actually be an advantage to do
> struct layout like the VAX did, with everything aligned on byte
> boundaries?  On the plus side, there would be lower memory use.
> On the minus side... very low cost, as you wrote above.

The correct spelling is "My 66000" this may come up later if
my trademark is accepted.

[toc] | [prev] | [next] | [standalone]

#110325 — Re: unaligned load/store

>> Aligned data is always best, Misaligned data comes at very low cost.
>> SW overhead = 0
> Thinking about this for a bit... for a clean-sheet architecture
> like My66000, could there actually be an advantage to do
> struct layout like the VAX did, with everything aligned on byte
> boundaries?

I highly doubt it.  Making unaligned accesses work efficiently is great,
but that's no reason to abuse them:

- Going back to Mitch's description, in case B.1 the misalignment is
  truly "free", but for B.2, B.3, and B.4 the misalignment does come at
  a cost, not necessarily visible in terms of cycles but at least in
  terms of cache bandwidth, which can have an impact on overall speed
  and energy use.
  Of course, properly aligning your data will also come with costs,
  but "packed structs" don't come totally free.
- AFAIK most efforts to support concurrency take it for granted that
  atomic accesses are supported only when properly aligned.

I expect it's at least as easy (and more portable) to reorder fields by
order of (expected) size to avoid excessive padding in aligned data,
than it is to add manual padding/alignment to avoid the cost of
misalignment in "packed structs".


        Stefan

[toc] | [prev] | [next] | [standalone]

#110334 — Re: unaligned load/store

On Thu, 26 Dec 2024 13:38:04 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>>> Aligned data is always best, Misaligned data comes at very low cost.
>>> SW overhead = 0
>> Thinking about this for a bit... for a clean-sheet architecture
>> like My66000, could there actually be an advantage to do
>> struct layout like the VAX did, with everything aligned on byte
>> boundaries?
>
>I highly doubt it.  Making unaligned accesses work efficiently is great,
>but that's no reason to abuse them:
>
>- Going back to Mitch's description, in case B.1 the misalignment is
>  truly "free", but for B.2, B.3, and B.4 the misalignment does come at
>  a cost, not necessarily visible in terms of cycles but at least in
>  terms of cache bandwidth, which can have an impact on overall speed
>  and energy use.
>  Of course, properly aligning your data will also come with costs,
>  but "packed structs" don't come totally free.
>- AFAIK most efforts to support concurrency take it for granted that
>  atomic accesses are supported only when properly aligned.
>
>I expect it's at least as easy (and more portable) to reorder fields by
>order of (expected) size to avoid excessive padding in aligned data,
>than it is to add manual padding/alignment to avoid the cost of
>misalignment in "packed structs".

It would have to be done manually in C or C++ because they don't
permit the compiler to reorder the fields of a struct.


>        Stefan

[toc] | [prev] | [next] | [standalone]

#110336 — Re: unaligned load/store

On Thu, 26 Dec 2024 18:38:04 +0000, Stefan Monnier wrote:

>>> Aligned data is always best, Misaligned data comes at very low cost.
>>> SW overhead = 0
>> Thinking about this for a bit... for a clean-sheet architecture
>> like My66000, could there actually be an advantage to do
>> struct layout like the VAX did, with everything aligned on byte
>> boundaries?
>
> I highly doubt it.  Making unaligned accesses work efficiently is great,
> but that's no reason to abuse them:

Agreed, highest performance comes when there are as few misaligned
memory references as possible, and when the penalty of misalignedness
is small--but DO NOT ABUSE this freedom.

> - Going back to Mitch's description, in case B.1 the misalignment is
>   truly "free", but for B.2, B.3, and B.4 the misalignment does come at
>   a cost, not necessarily visible in terms of cycles but at least in
>   terms of cache bandwidth, which can have an impact on overall speed
>   and energy use.
>   Of course, properly aligning your data will also come with costs,

Should be only memory footprint.

>   but "packed structs" don't come totally free.

There is NO REASON to make them slower than doable.

> - AFAIK most efforts to support concurrency take it for granted that
>   atomic accesses are supported only when properly aligned.

And you don't want multiple locks in the same cache line.

> I expect it's at least as easy (and more portable) to reorder fields by
> order of (expected) size to avoid excessive padding in aligned data,
> than it is to add manual padding/alignment to avoid the cost of
> misalignment in "packed structs".
>
>
>         Stefan

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.arch

csiph-web