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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#110337 — Re: unaligned load/store

On 12/26/2024 1:59 PM, MitchAlsup1 wrote:
> 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.

Exactly. This is a horrible mess of false sharing.


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

[...]

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

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

Jonathan Thornburg <jonathan@gold.bkis-orchard.net> writes:
>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.

Made me look up "millicode".  Anything at all might need a millicode
trap on implementations that use millicode, but I don't see any
particular issue here that would make millicode particularly relevant.

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

Again, sure, if you access a page that is not present, the hardware
traps to the OS to make that page present, but that's also the case
without unaligned accesses; and with software emulation of unaligned
accesses, as on Alpha with, e.g., UAC_NOPRINT, every unaligned access
traps to the OS.  Ist this better?

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

Possible, but hardly relevant.  E.g., I am interested in such things
and I was completely unaware of the penalties of unaligned stores
until I measured them: <http://al.howardknight.net/?ID=143135464800>
<https://www.complang.tuwien.ac.at/anton/unaligned-stores/>.  I expect
that even among performance-conscious programmers, only a small
minority knows more than to avoid them, when it's cheaply possible.

Maybe some (probably more than are aware of actual costs) think that
they should avoid them at all cost, and then use e.g., bytewise
approaches for hashing strings than the on-average faster approaches
that fetch string data as wide as is practical and hash that.

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

It's not just dusty deck Fortran code.

And the cost for not supporting unaligned accesses is higher.  There's
a reason why all surviving general-purpose architectures support
unaligned accesses.

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

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

#110196 — Re: bits and bytes, Keeping other stuff with addresses

It appears that Stefan Monnier  <monnier@iro.umontreal.ca> said:
>>>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. 

I don't see why.  We agree that nobody expects bit addressing to work, so
in fact those are flag bits.  You can use them to point at bits if you want
but there's no architectural or practical reason to do so.

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

On the PDP-10 you could have any byte size you wanted, but in fact it was always
7 bits since that was how many ASCII needed and five 7-bit characters fit in a
36 bit word with one bit left over that was used as a flag that the word
contained a five digit line number.

At this point the reason you use 8 bit bytes is that everyone else uses 8 bit
bytes. In about 1980 BBN had a 16 bit byte addressed machine called the C30 that
ran Unix and someone had the bright idea to expand the address space from 16 to
20 bits on the larger C70 by making the bytes 10 bits rather than 8. I talked to
someone who programmed it and told me that it was miserable because the C code
was full of implicit assumptions that bytes were 8 bits.

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

#110200 — Re: bits and bytes, Keeping other stuff with addresses

>>> Seems like an odd place to put what are in practice just flag bits.
>> It's a very natural one, tho.
> I don't see why.

The next sentence after the one you cited explained my reasoning.

> We agree that nobody expects bit addressing to work, so in fact those
> are flag bits.

In practice, yes.

> You can use them to point at bits if you want but there's no
> architectural or practical reason to do so.

Indeed, which is why we could use them for tag bits.


        Stefan

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

#110179 — Re: Keeping other stuff with addresses

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.

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

#110189 — Re: Keeping other stuff with addresses

On 12/3/2024 11:22 AM, MitchAlsup1 wrote:
> 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.

Stealing bit's wrt say, lock-free algorithms is usually about stealing 
from a pointer "value". think about C++'s std::uintptr_t, for a 
moment... Iirc, it may be optional, well, stealing bits from a pointer 
_value_ is non portable in and of itself. Although, they can be very 
useful, indeed... :^)

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

#110188 — Re: Keeping other stuff with addresses

On 12/3/2024 8:51 AM, Stefan Monnier wrote:
>> 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).

;^)

Wrt stealing bits I always revert back to the original pointer when I 
use it for anything to do with the system. Now, actually using the 
stolen bits, well we can over align on a _large_ boundary and use them 
for a smallish reference count and/or version counter. We can use them 
for state machines in some clever lock-free algorithms. We just need to 
only use the stolen bits for _our_ logic. Mask them off, get back to the 
original pointer "value" before we use that pointer for what's its 
pointing too. Never deference a pointer with stolen bits!!!!!!!!!!!!!!!!!!

Fair enough?

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

#110201 — Re: Keeping other stuff with addresses

> Never deference a pointer with stolen bits!!!!!!!!!!!!!!!!!!
> Fair enough?

+1


        Stefan

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

#110190 — Re: Keeping other stuff with addresses

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

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

#110193 — Re: Keeping other stuff with addresses

On Wed, 4 Dec 2024 1:43:15 +0000, Keith Thompson wrote:

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

Circa 1983: Lee Higbe (a CRAY compiler writer) told me that the symbol
table lookup process had been completely vectorized and this is why the
CRAY complier and assembler were so fast. Apparently, identifying
symbols and looking them up in the symbol table had been nearly
complete-
ly vectorized.

So, maybe C string functions are slow on word accessed CRAY machines,
But identifying what string of characters is a name and looking it up
in a symbol table CAN be vectorized with the semantics of normal
languages if not with the C intrinsics.

> (I'm using the past tense because I don't know whether any of these
> systems are still in use.)

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

#110105

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.

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

#110107

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.

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

#110108

MitchAlsup1 <mitchalsup@aol.com> wrote:
> 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.

Memory was so precious that using the top byte for other things was the
right choice.
Apple made the exact same choice with the MC68000 despite the track record,
or more correctly copying the track record in full knowledge of what
changes would come.

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

#110109

On Thu, 28 Nov 2024 17:56:23 -0000 (UTC), Thomas Koenig wrote:

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

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.

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

#110111

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. Most IBM mainframe shops write
some software themselves; that wasn't the case for Apple users in the
1980s. 

John 

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

#110112

jgd@cix.co.uk (John Dallman) writes:
> 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. 

Amdahl had won the battle to make ACS, 360 compatible, then when ACS/360
was canceled, he left IBM and formed his own 370 clone mainframe
company.
https://people.computing.clemson.edu/~mark/acs_end.html

Circa 1971, Amdahl gave talk in large MIT auditorium and somebody in the
audience asked him what justifications he used to attract investors and
he replied that even if IBM were to completely walk away from 370, there
was hundreds of billions in customer written 370 code that could keep
him in business through the end of the century.

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

trivia: during FS, internal politics was killing off 370 projects and
claims are the lack of new 370 products in the period is what gave the
clone 370 makers (including Amdahl) their market foothold. some more
info
http://www.jfsowa.com/computer/memo125.htm
when FS finally imploded, there was mad rush to get stuff back into the
370 product pipelines, including kicking off the quick&dirty 3033&3081
efforts.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#110113

In article <87frnbyo54.fsf@localhost>, lynn@garlic.com (Lynn Wheeler)
wrote:

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

He did, however, have an extensive knowledge of IBM senior management. At
the time it would have been plausible that they'd consider abandoning
360/370 in favour of something they thought better. 

John 

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

#110115 — IBM and Amdahl history (Re: What is an N-bit machine?)

Lynn Wheeler <lynn@garlic.com> writes:
>jgd@cix.co.uk (John Dallman) writes:
>Circa 1971, Amdahl gave talk in large MIT auditorium and somebody in the
>audience asked him what justifications he used to attract investors and
>he replied that even if IBM were to completely walk away from 370, there
>was hundreds of billions in customer written 370 code that could keep
>him in business through the end of the century.

And that was probably an understatement.  Legacy software is keeping
Unisys in business to this day, and the software ecosystem and
customer base of S/360 was larger in 1971 than the Burroughs large
systems and Univac lines that Unisys is still working with AFAIK.

OTOH, Amdahl corporation did not make it until the end of the century
(at least not on its own; it became a subsidiary of Fujitsu), for two
reasons having to do with IBM not walking away from the S/360 family:

1) IBM made the switch to CMOS and benefitted from the extremely fast
speedups in CMOS speed in the 1990s, while Amdahl failed to take that
step.

2) IBM extended the 32-bit s390 to the 64-bit s390x in 2000.
Fujitsu/Amdahl did not want to follow and essentially gave up that
market.

>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).
>
>trivia: during FS, internal politics was killing off 370 projects and
>claims are the lack of new 370 products in the period is what gave the
>clone 370 makers (including Amdahl) their market foothold. some more
>info
>http://www.jfsowa.com/computer/memo125.htm
>when FS finally imploded, there was mad rush to get stuff back into the
>370 product pipelines, including kicking off the quick&dirty 3033&3081
>efforts.

OTOH, FS eventually led to S/38 and the System i, which IBM sold
rather than introducing low-end S/370 (and later s390 and s390x)
members.  The way that Heinz Zemanek (head of IBM's Vienna Lab until
1976) told the story was that IBM was preparing to be divided up if
they lost the anti-trust action, and introduced S/38 and one other
line (that I don't remember) in addition to S/370 for that.

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

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

#110117 — Re: IBM and Amdahl history (Re: What is an N-bit machine?)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> OTOH, Amdahl corporation did not make it until the end of the century
> (at least not on its own; it became a subsidiary of Fujitsu), for two
> reasons having to do with IBM not walking away from the S/360 family:

a little history drift ... IBM communication group had corporate
strategic ownership of everything that crossed the datacenter walls and
was fiercely fighting off client/server and distributed computing
(trying to preserve its dumb terminal paradigm). Late 80s, a senior disk
engineer got a talk scheduled at a world-wide, internal, annual
communication group conference supposedly on 3174 performance but opened
the talk with statement that the communication group was going to be
responsible for the demise of the disk division; the disk division was
seeing data fleeing datacenter to more distributed computing friendly
platforms with drops in disk sales. The disk division had tried to come
up with a number of solutions, but they were constantly being vetoed by
the communication group.

One of the disk division executive's (partial) countermeasure was
investing in distributed computing startups that would use IBM disks
(and would periodically ask us to drop in on investments to see if we
could help).

It wasn't just disks but whole mainframe industry and a couple years
later IBM had one of the largest losses in the history of US
corporations and was being reorged into the 13 "baby blues" (a take-off
on the AT&T baby blues and its breakup a decade early) in preparation
for breaking up the company.
https://web.archive.org/web/20101120231857/http://www.time.com/time/magazine/article/0,9171,977353,00.html
https://content.time.com/time/subscriber/article/0,33009,977353-1,00.html
We had already left IBM but get a call from the bowels of Armonk
(corporate hdqtrs) asking if we could help with the breakup. Before we
get started, the board brings in the former AMEX president as CEO to try
and save the company, who (somewhat) reverses the breakup.

note AMEX had been in competition with KKR for LBO (private-equity)
take-over of RJR and KKR wins, it then runs into some difficulties and
hires away AMEX president to help
https://en.wikipedia.org/wiki/Barbarians_at_the_Gate:_The_Fall_of_RJR_Nabisco
later as IBM CEO, uses some of the same methods used at RJR:
https://web.archive.org/web/20181019074906/http://www.ibmemployee.com/RetirementHeist.shtml

In the 80s, IBM mainframe hardware was majority of IBM revenue but by
the turn of the century it was a few percent of revenue and dropping.
Around 2010-2013, mainframe hardware was a couple percent of IBM revenue
and still dropping, although the mainframe group was 25% of revenue (and
40% of profit) ... aka software and services.

... IBM was turning into a financial engineering company

IBM deliberately misclassified mainframe sales to enrich execs, lawsuit
claims. Lawsuit accuses Big Blue of cheating investors by shifting
systems revenue to trendy cloud, mobile tech
https://www.theregister.com/2022/04/07/ibm_securities_lawsuit/
IBM has been sued by investors who claim the company under former CEO
Ginni Rometty propped up its stock price and deceived shareholders by
misclassifying revenues from its non-strategic mainframe business - and
moving said sales to its strategic business segments - in violation of
securities regulations.

flash-back: mid-80s, the communication group had been blocking release
of mainframe TCP/IP ... but when that was reversed, it changed its
tactic and said that since they had strategic ownership of everything
that crossed datacenter walls, it had to be released through them; what
shipped got aggregate of 44kbut/sec using nearly whole 3090 processor. I
then add support for RFC1044 and in some tuning tests at Cray Research
between Cray and 4341, got sustained 4341 channel media throughput using
only modest amount of 4341 processor (something like 500 times
improvement in bytes moved per instruction executed).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#110118 — Re: IBM and Amdahl history (Re: What is an N-bit machine?)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Lynn Wheeler <lynn@garlic.com> writes:
>>jgd@cix.co.uk (John Dallman) writes:
>>Circa 1971, Amdahl gave talk in large MIT auditorium and somebody in the
>>audience asked him what justifications he used to attract investors and
>>he replied that even if IBM were to completely walk away from 370, there
>>was hundreds of billions in customer written 370 code that could keep
>>him in business through the end of the century.
>
>And that was probably an understatement.  Legacy software is keeping
>Unisys in business to this day, and the software ecosystem and
>customer base of S/360 was larger in 1971 than the Burroughs large
>systems and Univac lines that Unisys is still working with AFAIK.

I think the bulk of Unisys business, such as it is, is now consulting, rather than
the legacy clearpath lines.

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

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

Back to top | Article view | comp.arch

csiph-web