Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Computers are useless. They can only give you answers. -- Pablo Picasso


devel / comp.arch / Re: A (late) dicussion point in big vs little endian

SubjectAuthor
* A (late) dicussion point in big vs little endianThomas Koenig
`* Re: A (late) dicussion point in big vs little endianEricP
 `* Re: A (late) dicussion point in big vs little endianThomas Koenig
  +* Re: A (late) dicussion point in big vs little endianQuadibloc
  |`* Re: A (late) dicussion point in big vs little endianTerje Mathisen
  | `- Re: A (late) dicussion point in big vs little endianJohn Levine
  +- Re: A (late) dicussion point in big vs little endianMitchAlsup
  +* Re: A (late) dicussion point in big vs little endianTerje Mathisen
  |+* Re: A (late) dicussion point in big vs little endianThomas Koenig
  ||+- Re: A (late) dicussion point in big vs little endianJohn Levine
  ||`- Re: A (late) dicussion point in big vs little endianAnton Ertl
  |`- Re: A (late) dicussion point in big vs little endianMitchAlsup
  `* Re: A (late) dicussion point in big vs little endianEricP
   `- Re: A (late) dicussion point in big vs little endianMarcus

1
A (late) dicussion point in big vs little endian

<spsjto$kup$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22363&group=comp.arch#22363

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2a0a-a540-2738-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: A (late) dicussion point in big vs little endian
Date: Tue, 21 Dec 2021 13:13:28 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spsjto$kup$1@newsreader4.netcologne.de>
Injection-Date: Tue, 21 Dec 2021 13:13:28 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2a0a-a540-2738-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2a0a:a540:2738:0:7285:c2ff:fe6c:992d";
logging-data="21465"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 21 Dec 2021 13:13 UTC

The ship has pretty much sailed for big vs. little endian.

The Datapoint 2200 was a bit-serial design, which of course needs
little-endian words, Intel created the 8008 with that ISA, IBM
chose its successor 8086 for the PC, and PCs rolled up the market.

Which is better is a holy war of the past, now. I have only
been able to find one valid point: Comparing multiple bytes, for
example in memcmp. For big-engian, you can compare words, and the
results will be the same if you compared the bytes individually.
For little-endian, this is not the case, as the following test
program shows.

#include <stdio.h>
#include <string.h>

char a[4];
char b[4] = {1, 0, 0, 1};

int main()
{ unsigned int ai, bi;
for (int i=0; i<3; i++) {
a[0] = i;
for (int j=0; j<3; j++) {
a[3] = j;
memcpy (&ai, a, sizeof(int));
memcpy (&bi, b, sizeof(int));
printf ("ai < bi = %d,", ai < bi);
printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
}

return 0;
}

For an efficient memcmp on a big-endian machine, byte reversal is
needed (this can also be seen, for example, in the source of glibc).

It might make sense to put that into the load/store instructions
if the encoding and the timing allow.

Re: A (late) dicussion point in big vs little endian

<RfnwJ.80055$zF3.63352@fx03.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22365&group=comp.arch#22365

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
References: <spsjto$kup$1@newsreader4.netcologne.de>
In-Reply-To: <spsjto$kup$1@newsreader4.netcologne.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 53
Message-ID: <RfnwJ.80055$zF3.63352@fx03.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Tue, 21 Dec 2021 16:27:29 UTC
Date: Tue, 21 Dec 2021 11:24:49 -0500
X-Received-Bytes: 2481
 by: EricP - Tue, 21 Dec 2021 16:24 UTC

Thomas Koenig wrote:
> The ship has pretty much sailed for big vs. little endian.
>
> The Datapoint 2200 was a bit-serial design, which of course needs
> little-endian words, Intel created the 8008 with that ISA, IBM
> chose its successor 8086 for the PC, and PCs rolled up the market.
>
> Which is better is a holy war of the past, now. I have only
> been able to find one valid point: Comparing multiple bytes, for
> example in memcmp. For big-engian, you can compare words, and the
> results will be the same if you compared the bytes individually.
> For little-endian, this is not the case, as the following test
> program shows.
>
> #include <stdio.h>
> #include <string.h>
>
> char a[4];
> char b[4] = {1, 0, 0, 1};
>
> int main()
> {
> unsigned int ai, bi;
> for (int i=0; i<3; i++) {
> a[0] = i;
> for (int j=0; j<3; j++) {
> a[3] = j;
> memcpy (&ai, a, sizeof(int));
> memcpy (&bi, b, sizeof(int));
> printf ("ai < bi = %d,", ai < bi);
> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
> }
>
> return 0;
> }
>
> For an efficient memcmp on a big-endian machine, byte reversal is
> needed (this can also be seen, for example, in the source of glibc).
>
> It might make sense to put that into the load/store instructions
> if the encoding and the timing allow.

Right, to compare two multi-word values you start at the high end,
wherever the high end is located, and move towards the low end.

On the other hand, to add two multi-word values you start at the low end,
wherever the low end is located and move towards the high end.

Next, stacks - grow down or grow up?
SP points to last slot used or next slot empty?
It's a conundrum.

Re: A (late) dicussion point in big vs little endian

<spuoa2$3i2$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22370&group=comp.arch#22370

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-c1ea-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 08:40:34 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spuoa2$3i2$1@newsreader4.netcologne.de>
References: <spsjto$kup$1@newsreader4.netcologne.de>
<RfnwJ.80055$zF3.63352@fx03.iad>
Injection-Date: Wed, 22 Dec 2021 08:40:34 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-c1ea-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:c1ea:0:7285:c2ff:fe6c:992d";
logging-data="3650"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 22 Dec 2021 08:40 UTC

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Thomas Koenig wrote:
>> The ship has pretty much sailed for big vs. little endian.
>>
>> The Datapoint 2200 was a bit-serial design, which of course needs
>> little-endian words, Intel created the 8008 with that ISA, IBM
>> chose its successor 8086 for the PC, and PCs rolled up the market.
>>
>> Which is better is a holy war of the past, now. I have only
>> been able to find one valid point: Comparing multiple bytes, for
>> example in memcmp. For big-engian, you can compare words, and the
>> results will be the same if you compared the bytes individually.
>> For little-endian, this is not the case, as the following test
>> program shows.
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> char a[4];
>> char b[4] = {1, 0, 0, 1};
>>
>> int main()
>> {
>> unsigned int ai, bi;
>> for (int i=0; i<3; i++) {
>> a[0] = i;
>> for (int j=0; j<3; j++) {
>> a[3] = j;
>> memcpy (&ai, a, sizeof(int));
>> memcpy (&bi, b, sizeof(int));
>> printf ("ai < bi = %d,", ai < bi);
>> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
>> }
>>
>> return 0;
>> }
>>
>> For an efficient memcmp on a big-endian machine, byte reversal is
>> needed (this can also be seen, for example, in the source of glibc).
>>
>> It might make sense to put that into the load/store instructions
>> if the encoding and the timing allow.
>
> Right, to compare two multi-word values you start at the high end,
> wherever the high end is located, and move towards the low end.
>
> On the other hand, to add two multi-word values you start at the low end,
> wherever the low end is located and move towards the high end.

There is one bit of difference: How summation is arranged does
not matter (much) for performance as long as the whole word
is read in in one chunk. For little-endian, you have to do
some instruction for byte swapping for memcmp().

Re: A (late) dicussion point in big vs little endian

<f45f4154-bdd7-4284-9b69-bfe5ab3d1671n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22371&group=comp.arch#22371

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr2359711qka.274.1640187362182;
Wed, 22 Dec 2021 07:36:02 -0800 (PST)
X-Received: by 2002:a05:6808:211c:: with SMTP id r28mr1198826oiw.155.1640187361851;
Wed, 22 Dec 2021 07:36:01 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 22 Dec 2021 07:36:01 -0800 (PST)
In-Reply-To: <spuoa2$3i2$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:4d30:2f75:206:46b7;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:4d30:2f75:206:46b7
References: <spsjto$kup$1@newsreader4.netcologne.de> <RfnwJ.80055$zF3.63352@fx03.iad>
<spuoa2$3i2$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f45f4154-bdd7-4284-9b69-bfe5ab3d1671n@googlegroups.com>
Subject: Re: A (late) dicussion point in big vs little endian
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Wed, 22 Dec 2021 15:36:02 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 31
 by: Quadibloc - Wed, 22 Dec 2021 15:36 UTC

On Wednesday, December 22, 2021 at 1:40:37 AM UTC-7, Thomas Koenig wrote:

> There is one bit of difference: How summation is arranged does
> not matter (much) for performance as long as the whole word
> is read in in one chunk. For little-endian, you have to do
> some instruction for byte swapping for memcmp().

That's a new point, but comparison versus addition was noted at the
very beginning of the little-endian versus big-endian argument.

A while back, I pointed out another argument for big-endian that I
hadn't seen, but it may have been around.

If a computer has a packed decimal data type, then big-endian has
an advantage because:

Packed decimal is meant to facilitate arithmetic on numbers contained
in character strings. The character strings have big-endian order, so
packed decimal should be big-endian to facilitate this.

Because the zone bits are squeezed out, packed decimal resembles binary;
an arithmetic unit could handle both packed decimal and binary if you could
change what was done to generate carries for every four bits. But that only
works conveniently when packed decimal and binary have the same endianness.

Of course, the IBM System/360, which has packed decimal, is big-endian.

This may not be a decisive point to some, because some will question
whether or not there is any need for packed decimal arithmetic in a
computer.

John Savard

Re: A (late) dicussion point in big vs little endian

<c3b37b23-6f6d-459a-b465-e300c9e6775fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22372&group=comp.arch#22372

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:b8b:: with SMTP id k11mr2389319qkh.746.1640188697380;
Wed, 22 Dec 2021 07:58:17 -0800 (PST)
X-Received: by 2002:a05:6830:1445:: with SMTP id w5mr2480575otp.112.1640188697049;
Wed, 22 Dec 2021 07:58:17 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 22 Dec 2021 07:58:16 -0800 (PST)
In-Reply-To: <spuoa2$3i2$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:d585:69e5:7c3c:887c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:d585:69e5:7c3c:887c
References: <spsjto$kup$1@newsreader4.netcologne.de> <RfnwJ.80055$zF3.63352@fx03.iad>
<spuoa2$3i2$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c3b37b23-6f6d-459a-b465-e300c9e6775fn@googlegroups.com>
Subject: Re: A (late) dicussion point in big vs little endian
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 22 Dec 2021 15:58:17 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 64
 by: MitchAlsup - Wed, 22 Dec 2021 15:58 UTC

On Wednesday, December 22, 2021 at 2:40:37 AM UTC-6, Thomas Koenig wrote:
> EricP <ThatWould...@thevillage.com> schrieb:
> > Thomas Koenig wrote:
> >> The ship has pretty much sailed for big vs. little endian.
> >>
> >> The Datapoint 2200 was a bit-serial design, which of course needs
> >> little-endian words, Intel created the 8008 with that ISA, IBM
> >> chose its successor 8086 for the PC, and PCs rolled up the market.
> >>
> >> Which is better is a holy war of the past, now. I have only
> >> been able to find one valid point: Comparing multiple bytes, for
> >> example in memcmp. For big-engian, you can compare words, and the
> >> results will be the same if you compared the bytes individually.
> >> For little-endian, this is not the case, as the following test
> >> program shows.
> >>
> >> #include <stdio.h>
> >> #include <string.h>
> >>
> >> char a[4];
> >> char b[4] = {1, 0, 0, 1};
> >>
> >> int main()
> >> {
> >> unsigned int ai, bi;
> >> for (int i=0; i<3; i++) {
> >> a[0] = i;
> >> for (int j=0; j<3; j++) {
> >> a[3] = j;
> >> memcpy (&ai, a, sizeof(int));
> >> memcpy (&bi, b, sizeof(int));
> >> printf ("ai < bi = %d,", ai < bi);
> >> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
> >> }
> >>
> >> return 0;
> >> }
> >>
> >> For an efficient memcmp on a big-endian machine, byte reversal is
> >> needed (this can also be seen, for example, in the source of glibc).
> >>
> >> It might make sense to put that into the load/store instructions
> >> if the encoding and the timing allow.
> >
> > Right, to compare two multi-word values you start at the high end,
> > wherever the high end is located, and move towards the low end.
> >
> > On the other hand, to add two multi-word values you start at the low end,
> > wherever the low end is located and move towards the high end.
<
> There is one bit of difference: How summation is arranged does
> not matter (much) for performance as long as the whole word
> is read in in one chunk. For little-endian, you have to do
> some instruction for byte swapping for memcmp().
<
People like Little Endian for performing (integer) arithmetic on
strings because the carries need to move in LE fashion and the
overall is more efficient.
<
People like Big Endian for performing (nteger) compares on strings
because there is no-need for carries to determine the result and thus it
is more efficient top-to-bottom.
<
So, it seems to me the difference is the carry (lack or presence) not
the order in memory.

Re: A (late) dicussion point in big vs little endian

<spvihg$v3v$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22373&group=comp.arch#22373

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!rd9pRsUZyxkRLAEK7e/Uzw.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 17:08:18 +0100
Organization: Aioe.org NNTP Server
Message-ID: <spvihg$v3v$1@gioia.aioe.org>
References: <spsjto$kup$1@newsreader4.netcologne.de>
<RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="31871"; posting-host="rd9pRsUZyxkRLAEK7e/Uzw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.10.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Wed, 22 Dec 2021 16:08 UTC

Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>> Thomas Koenig wrote:
>>> The ship has pretty much sailed for big vs. little endian.
>>>
>>> The Datapoint 2200 was a bit-serial design, which of course needs
>>> little-endian words, Intel created the 8008 with that ISA, IBM
>>> chose its successor 8086 for the PC, and PCs rolled up the market.
>>>
>>> Which is better is a holy war of the past, now. I have only
>>> been able to find one valid point: Comparing multiple bytes, for
>>> example in memcmp. For big-engian, you can compare words, and the
>>> results will be the same if you compared the bytes individually.
>>> For little-endian, this is not the case, as the following test
>>> program shows.
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>> char a[4];
>>> char b[4] = {1, 0, 0, 1};
>>>
>>> int main()
>>> {
>>> unsigned int ai, bi;
>>> for (int i=0; i<3; i++) {
>>> a[0] = i;
>>> for (int j=0; j<3; j++) {
>>> a[3] = j;
>>> memcpy (&ai, a, sizeof(int));
>>> memcpy (&bi, b, sizeof(int));
>>> printf ("ai < bi = %d,", ai < bi);
>>> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> For an efficient memcmp on a big-endian machine, byte reversal is
>>> needed (this can also be seen, for example, in the source of glibc).

Since you only need to swap once, at the very end, after detecting the
first word with a difference, it _really_ doesn't matter.
>>>
>>> It might make sense to put that into the load/store instructions
>>> if the encoding and the timing allow.
>>
>> Right, to compare two multi-word values you start at the high end,
>> wherever the high end is located, and move towards the low end.
>>
>> On the other hand, to add two multi-word values you start at the low end,
>> wherever the low end is located and move towards the high end.
>
> There is one bit of difference: How summation is arranged does
> not matter (much) for performance as long as the whole word
> is read in in one chunk. For little-endian, you have to do
> some instruction for byte swapping for memcmp().

Again, see above: You just test for equality, then handle endian issues
at the end.

Terje

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

Re: A (late) dicussion point in big vs little endian

<spvil2$v3v$2@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22374&group=comp.arch#22374

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!rd9pRsUZyxkRLAEK7e/Uzw.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 17:10:12 +0100
Organization: Aioe.org NNTP Server
Message-ID: <spvil2$v3v$2@gioia.aioe.org>
References: <spsjto$kup$1@newsreader4.netcologne.de>
<RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de>
<f45f4154-bdd7-4284-9b69-bfe5ab3d1671n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="31871"; posting-host="rd9pRsUZyxkRLAEK7e/Uzw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.10.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Wed, 22 Dec 2021 16:10 UTC

Quadibloc wrote:
> On Wednesday, December 22, 2021 at 1:40:37 AM UTC-7, Thomas Koenig wrote:
>
>> There is one bit of difference: How summation is arranged does
>> not matter (much) for performance as long as the whole word
>> is read in in one chunk. For little-endian, you have to do
>> some instruction for byte swapping for memcmp().
>
> That's a new point, but comparison versus addition was noted at the
> very beginning of the little-endian versus big-endian argument.
>
> A while back, I pointed out another argument for big-endian that I
> hadn't seen, but it may have been around.
>
> If a computer has a packed decimal data type, then big-endian has
> an advantage because:
>
> Packed decimal is meant to facilitate arithmetic on numbers contained
> in character strings. The character strings have big-endian order, so
> packed decimal should be big-endian to facilitate this.
>
> Because the zone bits are squeezed out, packed decimal resembles binary;
> an arithmetic unit could handle both packed decimal and binary if you could
> change what was done to generate carries for every four bits. But that only
> works conveniently when packed decimal and binary have the same endianness.
>
> Of course, the IBM System/360, which has packed decimal, is big-endian.
>
> This may not be a decisive point to some, because some will question
> whether or not there is any need for packed decimal arithmetic in a
> computer.

Rather, I would question need to store packed decimal in little endian
order, if this should become a performance issue.

Terje

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

Re: A (late) dicussion point in big vs little endian

<spvkuv$mid$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22375&group=comp.arch#22375

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-c1ea-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 16:49:35 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <spvkuv$mid$1@newsreader4.netcologne.de>
References: <spsjto$kup$1@newsreader4.netcologne.de>
<RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de>
<spvihg$v3v$1@gioia.aioe.org>
Injection-Date: Wed, 22 Dec 2021 16:49:35 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-c1ea-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:c1ea:0:7285:c2ff:fe6c:992d";
logging-data="23117"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Wed, 22 Dec 2021 16:49 UTC

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>> Thomas Koenig wrote:
>>>> The ship has pretty much sailed for big vs. little endian.
>>>>
>>>> The Datapoint 2200 was a bit-serial design, which of course needs
>>>> little-endian words, Intel created the 8008 with that ISA, IBM
>>>> chose its successor 8086 for the PC, and PCs rolled up the market.
>>>>
>>>> Which is better is a holy war of the past, now. I have only
>>>> been able to find one valid point: Comparing multiple bytes, for
>>>> example in memcmp. For big-engian, you can compare words, and the
>>>> results will be the same if you compared the bytes individually.
>>>> For little-endian, this is not the case, as the following test
>>>> program shows.
>>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> char a[4];
>>>> char b[4] = {1, 0, 0, 1};
>>>>
>>>> int main()
>>>> {
>>>> unsigned int ai, bi;
>>>> for (int i=0; i<3; i++) {
>>>> a[0] = i;
>>>> for (int j=0; j<3; j++) {
>>>> a[3] = j;
>>>> memcpy (&ai, a, sizeof(int));
>>>> memcpy (&bi, b, sizeof(int));
>>>> printf ("ai < bi = %d,", ai < bi);
>>>> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
>>>> }
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> For an efficient memcmp on a big-endian machine, byte reversal is
>>>> needed (this can also be seen, for example, in the source of glibc).
>
> Since you only need to swap once, at the very end, after detecting the
> first word with a difference, it _really_ doesn't matter.

Fair enough.

There is just one (extremely minor) point left: You might not need
a byte-swap instruction on a big-endian architecture. Network
byte order happens to be big-endian and you can do the memcmp
without it.

(POWER, for example, only gained that instruction for the VSX
registers, which were introduced rather late).

Re: A (late) dicussion point in big vs little endian

<QOIwJ.156662$3q9.28000@fx47.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22376&group=comp.arch#22376

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.de!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
References: <spsjto$kup$1@newsreader4.netcologne.de> <RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de>
In-Reply-To: <spuoa2$3i2$1@newsreader4.netcologne.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 77
Message-ID: <QOIwJ.156662$3q9.28000@fx47.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Wed, 22 Dec 2021 16:58:24 UTC
Date: Wed, 22 Dec 2021 11:44:07 -0500
X-Received-Bytes: 3980
 by: EricP - Wed, 22 Dec 2021 16:44 UTC

Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>> Thomas Koenig wrote:
>>> The ship has pretty much sailed for big vs. little endian.
>>>
>>> The Datapoint 2200 was a bit-serial design, which of course needs
>>> little-endian words, Intel created the 8008 with that ISA, IBM
>>> chose its successor 8086 for the PC, and PCs rolled up the market.
>>>
>>> Which is better is a holy war of the past, now. I have only
>>> been able to find one valid point: Comparing multiple bytes, for
>>> example in memcmp. For big-engian, you can compare words, and the
>>> results will be the same if you compared the bytes individually.
>>> For little-endian, this is not the case, as the following test
>>> program shows.
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>> char a[4];
>>> char b[4] = {1, 0, 0, 1};
>>>
>>> int main()
>>> {
>>> unsigned int ai, bi;
>>> for (int i=0; i<3; i++) {
>>> a[0] = i;
>>> for (int j=0; j<3; j++) {
>>> a[3] = j;
>>> memcpy (&ai, a, sizeof(int));
>>> memcpy (&bi, b, sizeof(int));
>>> printf ("ai < bi = %d,", ai < bi);
>>> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> For an efficient memcmp on a big-endian machine, byte reversal is
>>> needed (this can also be seen, for example, in the source of glibc).
>>>
>>> It might make sense to put that into the load/store instructions
>>> if the encoding and the timing allow.
>> Right, to compare two multi-word values you start at the high end,
>> wherever the high end is located, and move towards the low end.
>>
>> On the other hand, to add two multi-word values you start at the low end,
>> wherever the low end is located and move towards the high end.
>
> There is one bit of difference: How summation is arranged does
> not matter (much) for performance as long as the whole word
> is read in in one chunk. For little-endian, you have to do
> some instruction for byte swapping for memcmp().

You are doing a multiple byte SIMD compare in a 32 bit register.
Just have proper SIMD compare instructions that order the
operand fields low to high.
(Besides on either hardware if the string buffer length is not a nice
multiple of 4 you are going to spend more instructions fiddling about
with the string tail than the swap would ever cost.)

Summation does matter as branch and mem[reg+offset] occur a lot.
There is an advantage to little endian on simple 8 bit processors
(e.g. 8080) with 16 bit immediates like branch offsets or register offsets.
The low byte of the offset can be fetched and routed directly to the
ALU and added in the same clock with the result saved in a temp reg.
Then the high byte is fetched directly into the ALU,
add with temp-carry and saved in a temp reg.
Then move temp to PC for branch or Mem Address Reg (MAR) for memory access.
Takes 3 cycles.

With a big endian offset the high byte is read first and must be saved
in a temp reg, then the low byte is read and routed direct to the ALU,
then high byte added, then move temp result to PC or MAR.
Takes 4 cycles.

Re: A (late) dicussion point in big vs little endian

<9b905814-c5e6-47bc-a386-e13e7808ef58n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22377&group=comp.arch#22377

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1654:: with SMTP id y20mr2892222qtj.374.1640193435586;
Wed, 22 Dec 2021 09:17:15 -0800 (PST)
X-Received: by 2002:aca:2412:: with SMTP id n18mr1497123oic.119.1640193435340;
Wed, 22 Dec 2021 09:17:15 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 22 Dec 2021 09:17:15 -0800 (PST)
In-Reply-To: <spvihg$v3v$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:d585:69e5:7c3c:887c;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:d585:69e5:7c3c:887c
References: <spsjto$kup$1@newsreader4.netcologne.de> <RfnwJ.80055$zF3.63352@fx03.iad>
<spuoa2$3i2$1@newsreader4.netcologne.de> <spvihg$v3v$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9b905814-c5e6-47bc-a386-e13e7808ef58n@googlegroups.com>
Subject: Re: A (late) dicussion point in big vs little endian
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 22 Dec 2021 17:17:15 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 69
 by: MitchAlsup - Wed, 22 Dec 2021 17:17 UTC

On Wednesday, December 22, 2021 at 10:08:19 AM UTC-6, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > EricP <ThatWould...@thevillage.com> schrieb:
> >> Thomas Koenig wrote:
> >>> The ship has pretty much sailed for big vs. little endian.
> >>>
> >>> The Datapoint 2200 was a bit-serial design, which of course needs
> >>> little-endian words, Intel created the 8008 with that ISA, IBM
> >>> chose its successor 8086 for the PC, and PCs rolled up the market.
> >>>
> >>> Which is better is a holy war of the past, now. I have only
> >>> been able to find one valid point: Comparing multiple bytes, for
> >>> example in memcmp. For big-engian, you can compare words, and the
> >>> results will be the same if you compared the bytes individually.
> >>> For little-endian, this is not the case, as the following test
> >>> program shows.
> >>>
> >>> #include <stdio.h>
> >>> #include <string.h>
> >>>
> >>> char a[4];
> >>> char b[4] = {1, 0, 0, 1};
> >>>
> >>> int main()
> >>> {
> >>> unsigned int ai, bi;
> >>> for (int i=0; i<3; i++) {
> >>> a[0] = i;
> >>> for (int j=0; j<3; j++) {
> >>> a[3] = j;
> >>> memcpy (&ai, a, sizeof(int));
> >>> memcpy (&bi, b, sizeof(int));
> >>> printf ("ai < bi = %d,", ai < bi);
> >>> printf (" a < b = %d\n", memcmp (a, b, 4) < 0); }
> >>> }
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> For an efficient memcmp on a big-endian machine, byte reversal is
> >>> needed (this can also be seen, for example, in the source of glibc).
<
> Since you only need to swap once, at the very end, after detecting the
> first word with a difference, it _really_ doesn't matter.
<
Why not just compare bytes from the end towards the beginning ?
<
> >>>
> >>> It might make sense to put that into the load/store instructions
> >>> if the encoding and the timing allow.
> >>
> >> Right, to compare two multi-word values you start at the high end,
> >> wherever the high end is located, and move towards the low end.
> >>
> >> On the other hand, to add two multi-word values you start at the low end,
> >> wherever the low end is located and move towards the high end.
> >
> > There is one bit of difference: How summation is arranged does
> > not matter (much) for performance as long as the whole word
> > is read in in one chunk. For little-endian, you have to do
> > some instruction for byte swapping for memcmp().
> Again, see above: You just test for equality, then handle endian issues
> at the end.
>
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Re: A (late) dicussion point in big vs little endian

<spvtc6$1mnk$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22379&group=comp.arch#22379

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 19:13:10 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <spvtc6$1mnk$1@gal.iecc.com>
References: <spsjto$kup$1@newsreader4.netcologne.de> <spuoa2$3i2$1@newsreader4.netcologne.de> <f45f4154-bdd7-4284-9b69-bfe5ab3d1671n@googlegroups.com> <spvil2$v3v$2@gioia.aioe.org>
Injection-Date: Wed, 22 Dec 2021 19:13:10 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="56052"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <spsjto$kup$1@newsreader4.netcologne.de> <spuoa2$3i2$1@newsreader4.netcologne.de> <f45f4154-bdd7-4284-9b69-bfe5ab3d1671n@googlegroups.com> <spvil2$v3v$2@gioia.aioe.org>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Wed, 22 Dec 2021 19:13 UTC

According to Terje Mathisen <terje.mathisen@tmsw.no>:
>> This may not be a decisive point to some, because some will question
>> whether or not there is any need for packed decimal arithmetic in a
>> computer.
>
>Rather, I would question need to store packed decimal in little endian
>order, if this should become a performance issue.

The S/360 packed decimal format, which I think everyone else uses give
or take the sign representation, puts the sign in the low
nibble. So on the big-endian S/360 it has to find and fetch the low
byte before it can do anything else.

Its decimal instructions have an address and a fixed length in the
instruction, so finding the low byte is one add. Meh.

The earlier 1400 was de facto little endian. It was character addressable,
numbers stored low digit first with a special word mark bit on the high
digit. The 1620 addressing did the same thing although it was otherwise fairly
different from the 1400.

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

Re: A (late) dicussion point in big vs little endian

<sq01ub$263c$1@gal.iecc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22381&group=comp.arch#22381

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Wed, 22 Dec 2021 20:31:07 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <sq01ub$263c$1@gal.iecc.com>
References: <spsjto$kup$1@newsreader4.netcologne.de> <spuoa2$3i2$1@newsreader4.netcologne.de> <spvihg$v3v$1@gioia.aioe.org> <spvkuv$mid$1@newsreader4.netcologne.de>
Injection-Date: Wed, 22 Dec 2021 20:31:07 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="71788"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <spsjto$kup$1@newsreader4.netcologne.de> <spuoa2$3i2$1@newsreader4.netcologne.de> <spvihg$v3v$1@gioia.aioe.org> <spvkuv$mid$1@newsreader4.netcologne.de>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Wed, 22 Dec 2021 20:31 UTC

According to Thomas Koenig <tkoenig@netcologne.de>:
>There is just one (extremely minor) point left: You might not need
>a byte-swap instruction on a big-endian architecture. Network
>byte order happens to be big-endian and you can do the memcmp
>without it.

I think you're confusing cause and effect. Network byte order was
defined before the PDP-11 shipped, so at the time big-endian was
all there was.

I don't see reordering the bytes in packet headers as a large part
of the load on any systems I use.

Anywhere it matters like in routers, there's special hardware.

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

Re: A (late) dicussion point in big vs little endian

<sq1424$pjk$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22382&group=comp.arch#22382

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Thu, 23 Dec 2021 07:13:23 +0100
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <sq1424$pjk$1@dont-email.me>
References: <spsjto$kup$1@newsreader4.netcologne.de>
<RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de>
<QOIwJ.156662$3q9.28000@fx47.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 Dec 2021 06:13:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8cc570a481292e12806c2390ac8620b8";
logging-data="26228"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Ux8Coq9/tRr9nVgJfycbzG8L8q3YzzKE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
Cancel-Lock: sha1:56Ab+gPTQC4qe3rf8/IXHPk/cq0=
In-Reply-To: <QOIwJ.156662$3q9.28000@fx47.iad>
Content-Language: en-US
 by: Marcus - Thu, 23 Dec 2021 06:13 UTC

On 2021-12-22, EricP wrote:
> Thomas Koenig wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>> Thomas Koenig wrote:
>>>> The ship has pretty much sailed for big vs. little endian.
>>>>
>>>> The Datapoint 2200 was a bit-serial design, which of course needs
>>>> little-endian words, Intel created the 8008 with that ISA, IBM
>>>> chose its successor 8086 for the PC, and PCs rolled up the market.
>>>>
>>>> Which is better is a holy war of the past, now.  I have only
>>>> been able to find one valid point:  Comparing multiple bytes, for
>>>> example in memcmp.  For big-engian, you can compare words, and the
>>>> results will be the same if you compared the bytes individually.
>>>> For little-endian, this is not the case, as the following test
>>>> program shows.
>>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> char a[4];
>>>> char b[4] = {1, 0, 0, 1};
>>>>
>>>> int main()
>>>> {
>>>>   unsigned int ai, bi;
>>>>   for (int i=0; i<3; i++) {
>>>>       a[0] = i;
>>>>       for (int j=0; j<3; j++) {
>>>>     a[3] = j;
>>>>     memcpy (&ai, a, sizeof(int));
>>>>     memcpy (&bi, b, sizeof(int));
>>>>     printf ("ai < bi = %d,", ai < bi);
>>>>     printf (" a < b =  %d\n", memcmp (a, b, 4) < 0);      }
>>>>     }
>>>>
>>>>   return 0;
>>>> }
>>>>
>>>> For an efficient memcmp on a big-endian machine, byte reversal is
>>>> needed (this can also be seen, for example, in the source of glibc).
>>>>
>>>> It might make sense to put that into the load/store instructions
>>>> if the encoding and the timing allow.
>>> Right, to compare two multi-word values you start at the high end,
>>> wherever the high end is located, and move towards the low end.
>>>
>>> On the other hand, to add two multi-word values you start at the low
>>> end,
>>> wherever the low end is located and move towards the high end.
>>
>> There is one bit of difference:  How summation is arranged does
>> not matter (much) for performance as long as the whole word
>> is read in in one chunk.  For little-endian, you have to do
>> some instruction for byte swapping for memcmp().
>
> You are doing a multiple byte SIMD compare in a 32 bit register.
> Just have proper SIMD compare instructions that order the
> operand fields low to high.
> (Besides on either hardware if the string buffer length is not a nice
> multiple of 4 you are going to spend more instructions fiddling about
> with the string tail than the swap would ever cost.)
>
> Summation does matter as branch and mem[reg+offset] occur a lot.
> There is an advantage to little endian on simple 8 bit processors
> (e.g. 8080) with 16 bit immediates like branch offsets or register offsets.
> The low byte of the offset can be fetched and routed directly to the
> ALU and added in the same clock with the result saved in a temp reg.
> Then the high byte is fetched directly into the ALU,
> add with temp-carry and saved in a temp reg.
> Then move temp to PC for branch or Mem Address Reg (MAR) for memory access.
> Takes 3 cycles.

I'm pretty sure that's how the 6502 did it. I didn't understand why it
used little endian at the time, but it makes perfect sense from an 8-bit
ALU / 8-bit data bus / 16-bit address calculation point of view.

>
> With a big endian offset the high byte is read first and must be saved
> in a temp reg, then the low byte is read and routed direct to the ALU,
> then high byte added, then move temp result to PC or MAR.
> Takes 4 cycles.
>
>

Re: A (late) dicussion point in big vs little endian

<2021Dec23.101602@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=22383&group=comp.arch#22383

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: A (late) dicussion point in big vs little endian
Date: Thu, 23 Dec 2021 09:16:02 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 18
Distribution: world
Message-ID: <2021Dec23.101602@mips.complang.tuwien.ac.at>
References: <spsjto$kup$1@newsreader4.netcologne.de> <RfnwJ.80055$zF3.63352@fx03.iad> <spuoa2$3i2$1@newsreader4.netcologne.de> <spvihg$v3v$1@gioia.aioe.org> <spvkuv$mid$1@newsreader4.netcologne.de>
Injection-Info: reader02.eternal-september.org; posting-host="20c621988f30335d3491e516aa3b8925";
logging-data="9115"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0b971pfxNKlnu+9bQU2lI"
Cancel-Lock: sha1:W+sC68YHhvcEK/OOfBzaXqInLkI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 23 Dec 2021 09:16 UTC

Thomas Koenig <tkoenig@netcologne.de> writes:
>Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Since you only need to swap once, at the very end, after detecting the
>> first word with a difference, it _really_ doesn't matter.
....
>(POWER, for example, only gained that instruction for the VSX
>registers, which were introduced rather late).

PowerPC has had lwbrx from the start and it is implemented in the
PowerPC 601. AFAIK the 601 core is the same as the Power RSC, so I
expect that Power also had lwbrx at that time. If you mean an
reg->reg byte-swap instruction, I guess the need is reduced if you
have byte-swapping load and store instructions like lwbrx.

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

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor