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

#110639 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>>>
>>>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>>>
>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>>>>>
>>>>>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>>>>>
>>>>>>>>> I think "ALU can add up to n-bit numbers" is a reasonable
>>>>>>>>> definition for an n-bit architecture, which also fits the
>>>>>>>>> 16-bit 68000.  It does not fit the 360/30, or the Nova (but
>>>>>>>>> see de Castro's remark on the latter).
>>>>>>>>
>>>>>>>> To me, the phrase "n-bit architecture" should depend only on
>>>>>>>> such characteristics as are defined by the architecture, and
>>>>>>>> not depend on features of a particular implementation.  The
>>>>>>>> 360/30 has a 32-bit (or is it 64-bit?) architecture, but only
>>>>>>>> an 8-bit implementation.
>>>>>>>>
>>>>>>>> If I may add a personal note, it's disappointing that postings
>>>>>>>> in a group nominally devoted to computer architecture routinely
>>>>>>>> ignore the distinction between architecture and implementation.
>>>>>>>
>>>>>>> I'm well aware of that distinction.
>>>>>>
>>>>>> I expect most of the folks who participate in comp.arch are
>>>>>> aware of the distinction.  What I find disappointing are
>>>>>> postings that ignore or blur the distinction, so it's hard
>>>>>> to tell where one domain ends and the other begins.
>>>>>
>>>>> If you find discussions about how certain times were used
>>>>> in the past disappointing...  [..]
>>>>
>>>> That isn't what I said, nor was it what I meant.
>>>
>>> If it walks like a duck...
>>
>> That is nothing but a gratuitous personal insult.  Why do you
>> engage in such conduct?
>
> You quoted what I wrote out of context, and then expressed your
> disappointment at what I wrote.

No, I didn't.  I took some time just now to review the entire
thread.  Nothing of what I said about disappointment was about
anything you wrote in any of those postings.

> I restored the context, and
> you said you didn't mean what you had said.

Again, no.  I didn't mean what you thought I had said.  And
that wasn't what I said.

> And I find no insult in what I wrote, but as you are a native
> speaker, you may find something in there that I didn't put in.

I think most native speakers of English would read the statement
"If it walks like a duck..." as an indirect way of calling me
a liar.  In polite society I think most people would take
being called a liar as an insult.

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

#110643 — Re: Keeping other stuff with addresses

On 28/01/2025 02:05, Tim Rentsch wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
> 

>> And I find no insult in what I wrote, but as you are a native
>> speaker, you may find something in there that I didn't put in.
> 
> I think most native speakers of English would read the statement
> "If it walks like a duck..." as an indirect way of calling me
> a liar.  In polite society I think most people would take
> being called a liar as an insult.

I haven't been following this thread well - and in Tim's traditional 
manner, the long time delay between his replies means it would take a 
lot of effort to figure it all out.  So this is not a commentary on 
anything in the thread - it's just what I hope will be a little 
clarification for Thomas about the duck phrase.

However, as a native speaker of English, I'd like to correct Tim - or at 
least add more nuance.  "If it walks like a duck..." simply means "I 
think it is what it appears to be".  It does /not/ have any specific 
implication of calling someone a liar, unless it /appears/ that the 
person has been lying.  It is, however, a phrase unlikely to be used in 
a positive manner - it could be used when someone has clearly been 
hypocritical to call them a hypocrite, or other such things.

Is it an insult?  If the phrase is used appropriately, then it is just 
putting emphasis on something that other people - but perhaps not the 
poster in question - can see.  When someone uses that phrase about 
something you have written, it is time for reflection on what you have 
posted and how it might have appeared to others.  You don't take it as a 
personal insult - you think carefully about why others might see your 
writings as something warranting the response.  And you might ask for 
clarification.


It may also be that Thomas, as a non-native English speaker, has 
slightly misunderstood the idiom or its implications.  This happens 
sometimes, even to those like Thomas that write better English than the 
solid majority of native speakers.  Idioms can be tricky.  A classic one 
that I have seen a number of times is the phrase "thanks a bunch" used 
as genuine gratitude.  In English, it is invariably used sarcastically.

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

#110656 — Re: Keeping other stuff with addresses

David Brown <david.brown@hesbynett.no> schrieb:

> However, as a native speaker of English, I'd like to correct Tim - or at 
> least add more nuance.  "If it walks like a duck..." simply means "I 
> think it is what it appears to be".  It does /not/ have any specific 
> implication of calling someone a liar, unless it /appears/ that the 
> person has been lying.  It is, however, a phrase unlikely to be used in 
> a positive manner - it could be used when someone has clearly been 
> hypocritical to call them a hypocrite, or other such things.
>
> Is it an insult?  If the phrase is used appropriately, then it is just 
> putting emphasis on something that other people - but perhaps not the 
> poster in question - can see.  When someone uses that phrase about 
> something you have written, it is time for reflection on what you have 
> posted and how it might have appeared to others.  You don't take it as a 
> personal insult - you think carefully about why others might see your 
> writings as something warranting the response.  And you might ask for 
> clarification.

First, thanks for the clarification.

I have drawn my own conclusions from this thread:  I have put Tim
in my killfile.  If he understands other the way he does (and then
accuses them of "gratituitous insults") it makes little sense for
me to reply to him, and the best way to do it is not read his
posts at all.

@Tim: You can have the official last word, because I will not read
your reply.

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

#110166 — Re: Keeping other stuff with addresses

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.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#110349 — Re: Keeping other stuff with addresses

Terje Mathisen <terje.mathisen@tmsw.no> writes:

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

I understand.  I don't mind postings that talk about both
architectural issues and implementation issues as long as
a clear distinction is made about which is which.

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

#110137 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>> >>>>These days I'd say the relevant N is the size of arithmetic
>>> >>>>registers but a lot of marketers appear to disagree with me.  

>The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
>registers with 512 bits each.  Sure, they are used for arithmetic on a
>sequence of individually narrower data, but the registers have 512
>bits nonetheless.

Jeez, who knew you were a chip salesman.

I meant the main registers, for some straightforward version of main.
You are of course correct that there are special purpose registers
that are much wider but I don't think it's all that hard to see which
ones I meant.

Everyone agreed that all the models of S/360 were 32 bit machines, but the
implementations ranged from 8 bits for the /25 and /30 to 64 bits for
the /75.  I don't think it's very useful to argue about whether the various
models of 360 were 8, 16, 32, or 64 bit machines.

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

#110147

John Levine <johnl@taugh.com> writes:
>I meant the main registers, for some straightforward version of main.
>You are of course correct that there are special purpose registers
>that are much wider but I don't think it's all that hard to see which
>ones I meant.

I guess you mean the general-purpose registers, which is not a proper
definition, either, and it means that the criterion only applies to
architectures with general-purpose registers.

I tried to be more precise and as a criterion "address register size",
i.e., the size of a register that holds an address.  And I guess that
should be refined to the size of a register that holds one address (to
avoid the issue of vector registers containing addresses for
scatter/gather instructions).  This also makes it clear that this
criterion does not apply to machines like the IBM 704 and PDP-10 that
have two addresses per machine word, but for word-addressed machines
the word size makes it clear what is meant with "N-bit machine".  This
resulta in:

1) For word-addressed machines: the size of the word.

2) For byte-addressed machines: the size of a register that contains
one address.

These criteria agree with the usual understanding of the bitness of an
architecture for most architectures, with a few exceptions:

* The 68000 would be classified as 32-bit architecture, which agrees
  with the modern understanding, but not with the marketing as 16-bit
  CPU or 16/32-bit CPU at the time.

* Most CPUs described as 8-bit CPUs keep at least the program counter
  in a larger register, a number of them (6800, 8008 and its
  descendents) also have 16-bit data-address registers or
  register-pairs (at least HL for the 8008).  At the time they and the
  68000 were described as 8-bit (16-bit for the 68000) based on the
  implementation of having an 8-bit data bus, but that argument broke
  down with the 8088 and 68008.

* I am not that familiar with the old character-oriented
  architectures, such as the IBM 702; they apparently are not
  described as N-bit machines for any N, so we probably don't need to
  assign such a label to them nowadays.

* There were also fixed-word-length machines that were not binary,
  such as the IBM 7070.  Memory is described as consisting of words,
  so criterion 1 can be applied, except that it's not N-bit, but
  N-digit.

Anything else?

BTW, note that these are architectural (i.e., instruction-set-related)
criteria; an implementation can implement several instruction sets.
E.g., I can run programs for the 16-bit 8086 architecture, for the
32-bit IA-32 architecture and for the 64-bit AMD64 architecture on,
e.g., the recent AMD Ryzen 9 9950X and the Intel Core Ultra 9 285K.

>Everyone agreed that all the models of S/360 were 32 bit machines, but the
>implementations ranged from 8 bits for the /25 and /30 to 64 bits for
>the /75.

This sentence is contradictory.  All these implementations have 32-bit
general-purpose registers (otherwise they would not be S/360
implementations), which are address registers, and are therefore
32-bit architectures by your and my criteria.

You obviously mean something different about these implementations.
What is it?

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

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

#110154

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>John Levine <johnl@taugh.com> writes:
>>I meant the main registers, for some straightforward version of main.
>>You are of course correct that there are special purpose registers
>>that are much wider but I don't think it's all that hard to see which
>>ones I meant.
>
>I guess you mean the general-purpose registers, which is not a proper
>definition, either, and it means that the criterion only applies to
>architectures with general-purpose registers.
>
>I tried to be more precise and as a criterion "address register size",
>i.e., the size of a register that holds an address.  And I guess that
>should be refined to the size of a register that holds one address (to
>avoid the issue of vector registers containing addresses for
>scatter/gather instructions).  This also makes it clear that this
>criterion does not apply to machines like the IBM 704 and PDP-10 that
>have two addresses per machine word, but for word-addressed machines
>the word size makes it clear what is meant with "N-bit machine".  This
>resulta in:
>
>1) For word-addressed machines: the size of the word.
>
>2) For byte-addressed machines: the size of a register that contains
>one address.

3) For digit-addressed memory-to-memory machines, there are index
   registers of a fixed size which can contain a 'virtual' (base-relative)
   address.   There may or may not be an accumulator for fixed point
   or floating point use.  There is no "register" that supports
   a non-base-relative (i.e. physical or machine) address which
   may be much larger that that supported by an index register.

   The bitness of this architecture could be considered 4-bit (as
   the smallest addressible element) or 40-bit (since the processor
   to memory interface is 10 digits wide).

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

#110257

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> John Levine <johnl@taugh.com> writes:
>>I meant the main registers, for some straightforward version of main.
>>You are of course correct that there are special purpose registers
>>that are much wider but I don't think it's all that hard to see which
>>ones I meant.
> 
> I guess you mean the general-purpose registers, which is not a proper
> definition, either, and it means that the criterion only applies to
> architectures with general-purpose registers.
> 
> I tried to be more precise and as a criterion "address register size",
> i.e., the size of a register that holds an address.  And I guess that
> should be refined to the size of a register that holds one address (to
> avoid the issue of vector registers containing addresses for
> scatter/gather instructions).  This also makes it clear that this
> criterion does not apply to machines like the IBM 704 and PDP-10 that
> have two addresses per machine word, but for word-addressed machines
> the word size makes it clear what is meant with "N-bit machine".  This
> resulta in:
> 
> 1) For word-addressed machines: the size of the word.
> 
> 2) For byte-addressed machines: the size of a register that contains
> one address.
> 
> These criteria agree with the usual understanding of the bitness of an
> architecture for most architectures, with a few exceptions:
> 
> * The 68000 would be classified as 32-bit architecture, which agrees
>   with the modern understanding, but not with the marketing as 16-bit
>   CPU or 16/32-bit CPU at the time.
> 
> * Most CPUs described as 8-bit CPUs keep at least the program counter
>   in a larger register, a number of them (6800, 8008 and its
>   descendents) also have 16-bit data-address registers or
>   register-pairs (at least HL for the 8008).  At the time they and the
>   68000 were described as 8-bit (16-bit for the 68000) based on the
>   implementation of having an 8-bit data bus, but that argument broke
>   down with the 8088 and 68008.
> 
> * I am not that familiar with the old character-oriented
>   architectures, such as the IBM 702; they apparently are not
>   described as N-bit machines for any N, so we probably don't need to
>   assign such a label to them nowadays.

I am not familiar with IBM 702, but IBM 1401 is in a sense more
"interesting"

- core is read in 7 bit units (8 bit if you count parity which
  in only used for error checking).  6 bits are data bit, one
  is "word mark" playing important role in the architecture.
- there is single 6 bit data register, capable of holding a
  single character.
- arithmetic is done on 4-bit BCD digits.  IIRC usually non-digit
  characters in arithmetic are errors, but sometimes have spacial
  meaning.
- there are 2 address register, each 3 characters long.  Similarly
  3 memory locations each 3 characters long _may_ be designated
  as "index registers" (that was separately charged feature).
  Of course there is also program counter.
- instructions primary effect is on memory where they operate
  on variable length "words" usually delimited by "word marks".
  I do not remember is data register is programmer visible, but
  address registes are visible.
- instructions have variable length, from 1 to 8 characters.
  Normally end of instructions is signalled by "word mark".
- actual memory addresses are decimal up 16000 - 1, but use
  funky encoding.  Two bits are used to specify "index register".

There are later models which can use longer addreses and change
address length.

There was also Honeywell 200 which borrowed several parts of
1401 architecture, but added one more mark bit and switched to
purely binary addressing.  IIRC Honeywell 200 cound be switched
between 2 character (12 bit), 3 character and 4 character
addresses.  The last two version used 3 bit to choose index
register.

There were several other low-end "commercial" machines with
more or less strange arrangements.  One of Polish machines
used 16-bit core words and 16-bit instructions, had some
16-bit registers, but also 16-digit "accumulator" working
in BCD encoding.  So one could view it as 16-bit machine
or 16-digit machine (but decimal arithmetic could use
varying length, 16 digit was max of what hardware could
do directly).

> * There were also fixed-word-length machines that were not binary,
>   such as the IBM 7070.  Memory is described as consisting of words,
>   so criterion 1 can be applied, except that it's not N-bit, but
>   N-digit.
> 
> Anything else?
> 
> BTW, note that these are architectural (i.e., instruction-set-related)
> criteria; an implementation can implement several instruction sets.
> E.g., I can run programs for the 16-bit 8086 architecture, for the
> 32-bit IA-32 architecture and for the 64-bit AMD64 architecture on,
> e.g., the recent AMD Ryzen 9 9950X and the Intel Core Ultra 9 285K.
> 
>>Everyone agreed that all the models of S/360 were 32 bit machines, but the
>>implementations ranged from 8 bits for the /25 and /30 to 64 bits for
>>the /75.
> 
> This sentence is contradictory.  All these implementations have 32-bit
> general-purpose registers (otherwise they would not be S/360
> implementations), which are address registers, and are therefore
> 32-bit architectures by your and my criteria.
> 
> You obviously mean something different about these implementations.
> What is it?

IIUC from hardware point of view 360/20, 360/25 and corresponding
model in 370 family were micros with rathere short word which
IBM equipped with emulation program which emulated 360 instruction
set.  I do not remember exact details for each of them, but at
least one executed emulation program ("microcode") from the same
16-bit physical core are "360 memory".  360 architectural registers
were just locations in core.  IIUC running programs on real
 hardware was unsupported by IBM, but nothing technically stopped
customers from doing this.  A research team created experimental
Fortran compiler targeting the hardware and they reported that
programs compiled by their Fortran run 45 times faster than
IBM Fortran compiling to 360 instruction set which was then
interpreted by "microcode".

360/30 had 8-bit date bus and mixture of 8 and 16-bit registers.
Here microcode was stored in capacitove read-only memory, had
longish words (something like 60-bits) and microcode memory
access was 5 times faster than core access time.  Again,
360 architectural registers were stored in core memory (some
IBM models had faster "local core", I do not remember if
360/30 stored registers in "local core" or main core).

In 360/30 microcode memory was read-only, so unlike 2x models
was not usable to load programs or store data, but at least
in principle could be changed by users.  Namely, capacitive
memory used flat foil capacitors, with data correspondig
to pattern on conductive fields on the foil.  Simple tools
allowed to remove fields form "full" (or if you prefer "blank")
foil and in this way program desired content.

So, main difference between 2x models and modern machine
running an emulator (like Hercules) was that IBM said that
360 instruction set was "native" on 2x models (but 1401
mode was as native as 360 mode, one simply loaded different
IBM-provided emulation program).  If one takes IBM word
that 2x models hardware implements 360 instruction set
at face value, then I think one should also take vendor
claims of "bitness" at face value.  If one digs deeper,
then 2x models are 16 bit (or someting like mixed 16/19
bit) architecture emulating 32-bit architecture.

IIUC at that time some people made distinction between
processor (that is official user-visible thing) and
microprocessor (actual hardware).  First semicondutior
microprocessors were intended to be microprocessors in
this sense, that is to be used to implement different
user visible aspect.  In this spirit native architecture
of many home computers would be BASIC.  However, running
directly on microprocessor gives large performance benefits
so this was used by lot of sofware and hardware instruction
set was considerd as native one.  The old view lives in
IBM AS/400 series or whatever IBM calls their successors:
AFAICS "official" instruction set of those machines is
implemented by software and actual hardware is quit different
and may vary.

-- 
                              Waldek Hebisch

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

#110140 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Michael S <already5chosen@yahoo.com> writes:
>>On Sat, 30 Nov 2024 16:57:56 GMT
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:  
>>> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:  
>>> >>>John Levine <johnl@taugh.com> writes:  
>>> >>>>These days I'd say the relevant N is the size of arithmetic
>>> >>>>registers but a lot of marketers appear to disagree with me.  
> ...
>>John Levine said "arythmetic". Not logic, not move, not swizzle, not
>>load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs and
>>128 bits for output (integer multiplication).
>
> The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
> registers with 512 bits each.

Can you do a 512-bit addition with it natively?

> Sure, they are used for arithmetic on a
> sequence of individually narrower data, but the registers have 512
> bits nonetheless.

So, more of a 64-bit system.

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

#110146 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Michael S <already5chosen@yahoo.com> writes:
>>>On Sat, 30 Nov 2024 16:57:56 GMT
>>>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:  
>>>> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:  
>>>> >>>John Levine <johnl@taugh.com> writes:  
>>>> >>>>These days I'd say the relevant N is the size of arithmetic
>>>> >>>>registers but a lot of marketers appear to disagree with me.  
>> ...
>>>John Levine said "arythmetic". Not logic, not move, not swizzle, not
>>>load/store. The widest arythmetic on Intel/AMD is 64 bits for inputs and
>>>128 bits for output (integer multiplication).
>>
>> The widest arithmetic registers on AMD64 with AVX-512 are the ZMM
>> registers with 512 bits each.
>
>Can you do a 512-bit addition with it natively?

Whatever that may mean, it would not be relevant to the criterion,
which is "size of arithmetic registers".  However, John Levine has
modified his criterion in the meantime.

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

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

#110133 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>John Levine <johnl@taugh.com> writes:
>>S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
>>the high 8 bits of the register were ignored. That turned out to be a really bad
>>decision since a few instructions and a lot of programming conventions stored
>>other stuff in that high byte, causing severe pain a few years later when
>>memories got bigger than 16 meg.
>
>The technique of putting stuff in unused bits of an address has its
>drawbacks, but it also has benefits, in particular type information is
>often stored there (even on architectures that do not ignore any
>bits).  Of course AMD and Intel have the bad examples of S/360 and
>68000 in mind, and did not want to have anything to do with that
>during the first two decades of AMD64.
>
>The designers of ARM A64 could think beyond that and designed in the
>top-byte-ignore feature.  Apparently this made AMD and Intel see the
>light:
>
>AMD added the upper-address ignore feature, which, when enabled,

 Architecturally known as Top Byte Ignore (TBI).  It can be
independently enabled for each half of the virtual address space
(based on the value of VA<55>).


>ignores the top 7 bits.  One problem with this in the Linux kernel
>(and maybe other OSs) is that the Linux kernel expects the top bit to
>be set only for kernel addresses.  Not sure how that works with ARMs
>top-byte ignore feature, which is supported since Linux 5.4 in 2019
>using the PR_SET_TAGGED_ADDR_CTRL option of the prctl() call.

Note that ARM64 also supports PAC (Pointer Authentication) instructions
which leverage the top byte to store a hash of the pointer, which
can be optionally checked during loads and stores.

>
>Intel added the linear address masking feature, with two variants:
>LAM_U57 ignores bits 57-62 (but not the MSB), allowing 6 bits for
>other uses; LAM_U48 ignores bits 48-62, allowing 15 bits for other
>uses.  These variants require bit 63 to have the same value as bit
>56/47; another bit could be made available by ignoring bit 56/47 (the
>information is in bit 63 anyway), but Intel apparently decided that
>programmers don't need that extra bit.
>

ARM64 also leverages TBI to support a Memory Tagging Extension which stores
tag bits in an external tag memory array (four bits for every
sixteen bytes of DRAM in the physical address space).  Loads and stores
to tagged regions will fault on a tag mismatch.

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

#110149 — Re: Keeping other stuff with addresses (was: What is an N-bit machine?)

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>John Levine <johnl@taugh.com> writes:
>>>S/360 had 24 bit addresses and 32 bit registers. When doing address arithmetic
>>>the high 8 bits of the register were ignored. That turned out to be a really bad
>>>decision since a few instructions and a lot of programming conventions stored
>>>other stuff in that high byte, causing severe pain a few years later when
>>>memories got bigger than 16 meg.
>>
>>The technique of putting stuff in unused bits of an address has its
>>drawbacks, but it also has benefits, in particular type information is
>>often stored there (even on architectures that do not ignore any
>>bits).  Of course AMD and Intel have the bad examples of S/360 and
>>68000 in mind, and did not want to have anything to do with that
>>during the first two decades of AMD64.
>>
>>The designers of ARM A64 could think beyond that and designed in the
>>top-byte-ignore feature.  Apparently this made AMD and Intel see the
>>light:
>>
>>AMD added the upper-address ignore feature, which, when enabled,
>
> Architecturally known as Top Byte Ignore (TBI).  It can be
>independently enabled for each half of the virtual address space
>(based on the value of VA<55>).
>
>
>>ignores the top 7 bits.

AMD calls it the upper-address ignore feature, and it does not ignore
the top byte.  As mentioned above ARM has the top-byte-ignore
feauture, which ignores the top byte.

Making a difference between kernel and user space is interesting.  The
kernel is usually not implemented in a programming language with
dynamic typing, so it does not need TBI for that reason; it may want
it for the other uses: pointer authentication and maybe memory
tagging.  At the kernel level pointer authentication sounds useful for
finding cases where addresses coming from user space are used without
first being checked (and converted to authenticated pointers).

The other direction is to have TBI for user space (for a process
running a Lisp program or somesuch), but not for the kernel space.
For the kernel this would allow techniques such as mapping physical
RAM into the kernel space even for RAM sizes up to 2^62 bytes ("only"
2^54 bytes, i.e., 16 Petabytes with the kernel in TBI mode).

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

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

#110161 — Re: Keeping other stuff with addresses

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!


> 
> The designers of ARM A64 could think beyond that and designed in the
> top-byte-ignore feature.  Apparently this made AMD and Intel see the
> light:
> 
> AMD added the upper-address ignore feature, which, when enabled,
> ignores the top 7 bits.  One problem with this in the Linux kernel
> (and maybe other OSs) is that the Linux kernel expects the top bit to
> be set only for kernel addresses.  Not sure how that works with ARMs
> top-byte ignore feature, which is supported since Linux 5.4 in 2019
> using the PR_SET_TAGGED_ADDR_CTRL option of the prctl() call.
> 
> Intel added the linear address masking feature, with two variants:
> LAM_U57 ignores bits 57-62 (but not the MSB), allowing 6 bits for
> other uses; LAM_U48 ignores bits 48-62, allowing 15 bits for other
> uses.  These variants require bit 63 to have the same value as bit
> 56/47; another bit could be made available by ignoring bit 56/47 (the
> information is in bit 63 anyway), but Intel apparently decided that
> programmers don't need that extra bit.
> 
> RISC-V has the pointer-masking extension, which ignores the top 7 bits
> (like AMD's upper-address ignore) or optionally 16 bits.
> 
> See <https://muxup.com/2023q4/storing-data-in-pointers> and
> <https://lwn.net/Articles/902094/>.
> 
> Concerning the kernel requirements, as someone who has implemented
> Prolog with tagging, having to untag on passing an address to the
> kernel would be only a minimal cost.  Not having to unmask on every
> memory access would be quite useful.  Having the top bit always be 0
> with the tags in the 6 bits below would not have been a restriction
> for us (we used 4-bit tags); OTOH, if one more bit was available,
> programmers would find good uses for it.
> 
>> These days I'd say the relevant N is the size of arithmetic registers but a
>> lot of marketers appear to disagree with me.
> 
> Which arithmetic registers on an Intel processor?  The 64 bits of a
> GPR?  The 128 bits of an XMM register?  The 256 bits of a YMM
> register?  The 512 bits of a ZMM register?  Note that until recently,
> Intel sold you the same silicon either with only XMM or with XMM and
> YMM registers.  They sell consumer CPUs with XMM, YMM, and ZMM
> registers, but more recent consumer and small-server CPUs have
> reverted to only supporting XMM and YMM registers.
> 
> - anton

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

#110162 — Re: Keeping other stuff with addresses

On Sun, 1 Dec 2024 23:22:14 +0000, Chris M. Thomasson wrote:

> On 11/29/2024 10:28 PM, Anton Ertl wrote:
>> John Levine <johnl@taugh.com> writes:
>>> S/360 had 24 bit addresses and 32 bit registers. When doing address
>>> arithmetic
>>> the high 8 bits of the register were ignored. That turned out to be a
>>> really bad
>>> decision since a few instructions and a lot of programming conventions
>>> stored
>>> other stuff in that high byte, causing severe pain a few years later
>>> when
>>> memories got bigger than 16 meg.
>>
>> The technique of putting stuff in unused bits of an address has its
>> drawbacks, but it also has benefits, in particular type information is
>> often stored there (even on architectures that do not ignore any
>> bits).  Of course AMD and Intel have the bad examples of S/360 and
>> 68000 in mind, and did not want to have anything to do with that
>> during the first two decades of AMD64.
>
> Fwiw, stealing bits from pointers is a common practice in exotic
> lock-free algorithms. It's not portable at all, but comes in handy!

How are you going to write these algorithms when a pointer consumes
all 64-bits of the register/memory container ?? VAS = 64-bits.

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

#110163 — Re: Keeping other stuff with addresses

On 12/1/2024 5:26 PM, MitchAlsup1 wrote:
> On Sun, 1 Dec 2024 23:22:14 +0000, Chris M. Thomasson wrote:
> 
>> On 11/29/2024 10:28 PM, Anton Ertl wrote:
>>> John Levine <johnl@taugh.com> writes:
>>>> S/360 had 24 bit addresses and 32 bit registers. When doing address
>>>> arithmetic
>>>> the high 8 bits of the register were ignored. That turned out to be a
>>>> really bad
>>>> decision since a few instructions and a lot of programming conventions
>>>> stored
>>>> other stuff in that high byte, causing severe pain a few years later
>>>> when
>>>> memories got bigger than 16 meg.
>>>
>>> The technique of putting stuff in unused bits of an address has its
>>> drawbacks, but it also has benefits, in particular type information is
>>> often stored there (even on architectures that do not ignore any
>>> bits).  Of course AMD and Intel have the bad examples of S/360 and
>>> 68000 in mind, and did not want to have anything to do with that
>>> during the first two decades of AMD64.
>>
>> Fwiw, stealing bits from pointers is a common practice in exotic
>> lock-free algorithms. It's not portable at all, but comes in handy!
> 
> How are you going to write these algorithms when a pointer consumes
> all 64-bits of the register/memory container ?? VAS = 64-bits.

You don't for they are not portable at all. However, on systems were we 
can steal some bits of a pointer value in C/C++, well, we can do it and 
create some interesting algorithms.

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

#110167 — Re: Keeping other stuff with addresses

On 12/1/2024 8:12 PM, Chris M. Thomasson wrote:
> On 12/1/2024 5:26 PM, MitchAlsup1 wrote:
>> On Sun, 1 Dec 2024 23:22:14 +0000, Chris M. Thomasson wrote:
>>
>>> On 11/29/2024 10:28 PM, Anton Ertl wrote:
>>>> John Levine <johnl@taugh.com> writes:
>>>>> S/360 had 24 bit addresses and 32 bit registers. When doing address
>>>>> arithmetic
>>>>> the high 8 bits of the register were ignored. That turned out to be a
>>>>> really bad
>>>>> decision since a few instructions and a lot of programming conventions
>>>>> stored
>>>>> other stuff in that high byte, causing severe pain a few years later
>>>>> when
>>>>> memories got bigger than 16 meg.
>>>>
>>>> The technique of putting stuff in unused bits of an address has its
>>>> drawbacks, but it also has benefits, in particular type information is
>>>> often stored there (even on architectures that do not ignore any
>>>> bits).  Of course AMD and Intel have the bad examples of S/360 and
>>>> 68000 in mind, and did not want to have anything to do with that
>>>> during the first two decades of AMD64.
>>>
>>> Fwiw, stealing bits from pointers is a common practice in exotic
>>> lock-free algorithms. It's not portable at all, but comes in handy!
>>
>> How are you going to write these algorithms when a pointer consumes
>> all 64-bits of the register/memory container ?? VAS = 64-bits.
> 
> You don't for they are not portable at all. However, on systems were we 
> can steal some bits of a pointer value in C/C++, well, we can do it and 
> create some interesting algorithms.

another way to steal bits is over alignment.

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

#110176 — Re: Keeping other stuff with addresses

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


        Stefan

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

#110177 — 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.
Some of the 1970s Burroughs machines were bit addressable at the microcode level
but I think they just used it to do different word sizes for different application
microcode.

The word=addressed PDP-6/10 could address bit fields just fine using byte
pointers that had address, offset, and size fields. It had load and store byte,
load and store after incrementing the pointer to the next byte, and on later
models, advance the pointer by N bytes. It was nice but 95% of the time they
were used in a single way to pack and unpack 7 bit ASCII characters in 36 bit
words.

R's,
John
-- 
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]

#110178 — Re: Keeping other stuff with addresses

>>> 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.
Just like the 21064 Alpha where they had byte-addressed memory but the
load/store instructions could only handle aligned words.


        Stefan

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

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

Back to top | Article view | comp.arch

csiph-web