About little big endian in C

[Joachim Schmitz]

"Richard Heathfield" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

Same format in the rest of Europe, only a different separator:
day.month.year
The UK format is pretty hard to distinguish from the US format

As compared to the big endian notation year.month.day used for example in
Japan,

The most sensible IMHO, makes sorting easiest.

and the braindead endian mixup month/day/year used in the USA. Indeed

Lets refine your currency example: numbers are written in big endian
decimal representation in English, but the same ordering of the digits in
Arabic is indeed little endian. The digits are different and the reading
order is still big endian though.

I think I've heard that Arabic uses the same little Endian for 2-digit
number as in Germany.

Yet in German, the reading order is different again: 42 is pronounced zwei
und vierzig, big endian writing, little endian reading (for 2 digits only
;-)

Actually for the last 2 digits of every number greater then 12.
A broken concept IMHO. I grew up with it and used all my life and still make
mistakes...
But not as broken as the french numbers between 70 and 99 (and
apparently fixed in the french speaking parts of Belgium and Switzerland)

Bye, Jojo

 

[Charlie Gordon]

Same format in the rest of Europe, only a different separator:
day.month.year
The UK format is pretty hard to distinguish from the US format

France uses day/month/year as well.

The most sensible IMHO, makes sorting easiest.

As long as year, month and day are formated with a fixed number of digits
;-)

I think I've heard that Arabic uses the same little Endian for 2-digit
number as in Germany.

Yes, I forgot about that! so it is consistently little endian for 2 digit
numbers. (above 11, and except multiples of 10 ;-)

Actually for the last 2 digits of every number greater then 12.

And for the low digit pairs in every group of three for larger numbers.

A broken concept IMHO. I grew up with it and used all my life and still
make mistakes...
But not as broken as the french numbers between 70 and 99 (and
apparently fixed in the french speaking parts of Belgium and Switzerland)

Not all numbers between 70 and 99, and not all parts of French speaking
Switzerland and Belgium: 80 to 89 are based on quatre-vingts in Belgium and
all but a few cantons in Switzerland... As usual, French language subtleties
are unfathomable: http://www.langue-fr.net/index/S/septante.htm -
http://fr.wikipedia.org/wiki/80_(nombre)

 

[Charlie Gordon]

user923005 wrote:
[...]

20.9: How can I determine whether a machine's byte order is big-
endian
or little-endian?

A: One way is to use a pointer:

int x = 1;
if(*(char *)&x == 1)
printf("little-endian\n");
else printf("big-endian\n");

It's also possible to use a union.

See also question 10.16.

References: H&S Sec. 6.1.2 pp. 163-4.

I supposed that, techincally, the answer is incomplete at best.
What happens on sizeof(char)==sizeof(int) systems? (And, on such
systems, is "endianness" even relevent?)

Then there are systems with some horrible mixed-endianned storage,
where the 32-bit value 0x11223344 would be stored: 22 11 44 33.
(Or is it 33 44 11 22?)

None still in production. You are refering to some PDP systems from more
than 30 years ago.

 

[Joachim Schmitz]

France uses day/month/year as well.

Really? OK, learned something new then...

As long as year, month and day are formated with a fixed number of digits
;-)

Very true

And for the low digit pairs in every group of three for larger numbers.

Ah, yes, indeed. As I said: a confusing and (therefor) broken concept...

 

[Ben Bacarisse]

"Richard Heathfield" <[email protected]> a écrit dans le message de
(e-mail address removed)...


As compared to the big endian notation year.month.day used for
example in Japan, and the braindead endian mixup month/day/year used
in the USA.

Lets refine your currency example: numbers are written in big endian decimal
representation in English, but the same ordering of the digits in Arabic is
indeed little endian.

.... in most of the original ancient forms the "denomination" (sheaves
of wheat, cattle, talents of silver) came, quote reasonably, after the
number in the reading order. Hence writing £39.99 is a nod to the
little-endian origin of the numbers.

 

[CBFalconer]

Same format in the rest of Europe, only a different separator:
day.month.year
The UK format is pretty hard to distinguish from the US format


The most sensible IMHO, makes sorting easiest.

Why do people keep using these obsolete formats, when there exists
an ISO standard for the operation (close to the Japanese format)?

 

[Keith Thompson]

"Kenneth Brody" <[email protected]> a écrit dans le message de
(e-mail address removed)... [...]

Then there are systems with some horrible mixed-endianned storage,
where the 32-bit value 0x11223344 would be stored: 22 11 44 33.
(Or is it 33 44 11 22?)

None still in production. You are refering to some PDP systems from more
than 30 years ago.

I'll bet there are still a few PDP-11s in production use.

 

[Keith Thompson]

The most sensible IMHO, makes sorting easiest.

ISO 8601 specifies YYYY-MM-DD; for example, today is 2007-10-20. It's
the format I use whenever I have a choice.

 

[Charlie Gordon]

"Kenneth Brody" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]

Then there are systems with some horrible mixed-endianned storage,
where the 32-bit value 0x11223344 would be stored: 22 11 44 33.
(Or is it 33 44 11 22?)

None still in production. You are refering to some PDP systems from more
than 30 years ago.

I'll bet there are still a few PDP-11s in production use.

Sorry, I meant none still being produced (manufactured) today.
PDP-11s in working order are worth some money for museums and collectors ;-)

 

[Charlie Gordon]

... in most of the original ancient forms the "denomination" (sheaves
of wheat, cattle, talents of silver) came, quote reasonably, after the
number in the reading order. Hence writing £39.99 is a nod to the
little-endian origin of the numbers.

Again, this is subject to cultural differences. In French, for example,
prices are usually written with the euro sign after the number,and
pronounced accordingly: "Ce logiciel est au prix de 21 ?"

 

[RoS]

In data Sat, 20 Oct 2007 03:22:42 +0200, Charlie Gordon scrisse:

"Richard Heathfield" <[email protected]> a écrit dans le message de
(e-mail address removed)...


As compared to the big endian notation year.month.day used for example in
Japan,
and the braindead endian mixup month/day/year used in the USA.

Lets refine your currency example: numbers are written in big endian decimal
representation in English, but the same ordering of the digits in Arabic is
indeed little endian. The digits are different and the reading order is
still big endian though. Yet in German, the reading order is different
again: 42 is pronounced zwei und vierzig, big endian writing, little endian
reading (for 2 digits only ;-)

the numbers for a computer are all little endian

if i have to do in decimal

0 0 9+
0 0 1
---------
0 0 0 1

you see the number grow in the right direction of memory
(if you see a potiner to 0 0 0 1 memory)

otherwise if the memory limit is found i know it

 

[Charlie Gordon]

the numbers for a computer are all little endian

if i have to do in decimal

0 0 9+
0 0 1
---------
0 0 0 1

you see the number grow in the right direction of memory
(if you see a potiner to 0 0 0 1 memory)

otherwise if the memory limit is found i know it

Little endian is definitely a more effective approach for computing variable
size bignums and bit arrays, etc. But it is less straight forward when it
comes to comparing these bignums ;-)

 

[karthikbalaguru]

Hello,

I am wondering when does the little or big endian affects the code ?
In which cases should I check if a machine uses Little or Big Endian?

- For example does it affect bitwise operations ? eg. x >> 10

- Does it affect operations like accessing memory with a (char *) ?
(in order to access individual bytes)

Any extra info/references is welcome

Thanks for your time and sorry for my (bad) english

Check this link ->
http://www.intel.com/design/intarch/papers/endian.pdf

It will be helpful for you.

Refer the section "Merits of Endian Architectures"
and the Table for clarifications w.r.t endiannes

DEC Alpha* - Little-Endian
Intel® 80x86 - Little-Endian
ARM* - Bi-Endian
HP PA-RISC 8000* - Bi-Endian
IBM PowerPC* - Bi-Endian
Intel® IXP network processors - Bi-Endian
Intel® Itanium® processor family - Bi-Endian
Java Virtual Machine* - Big-Endian
MIPS* - Bi-Endian
Motorola 68k* - Big-Endian
Sun SPARC* - Big-Endian


Also,
DEC Alpha computers are configurable for Big Endian
or Little Endian (that is, it is Bi-Endian as told
in wikipedia).


Table 2 contains examples of some common file formats
and the Endian order that they use:
=====================================================

Bus Protocols - Little Endian Format
------------------------------------------------------
Infiniband
PCI Express
PCI-32/PCI-64
USB

Network Protocols - Big Endian Format
-------------------------------------------------------------
TCP/IP
UDP

Bus Protocols - Bi-Endian Format
------------------------------------------------------
GMII (8 bit wide bus, no Endian issue)

Little-Endian Format
------------------------------
BMP (Windows* & OS/2)
GIF
FLI (Autodesk Animator*)
PCX (PC Paintbrush*)
QTM (MAC Quicktime*)
RTF (Rich Text Format)

Big-Endian Format
--------------------------------
PSD (Adobe Photoshop*)
IMG (GEM Raster*)
JPEG, JPG
MacPaint
SGI (Silicon Graphics*)
Sun Raster
WPG (WordPerfect*)

Variable or Bi-Endian Format
-------------------------------------------
DXF (AutoCAD*)
PS (Postscript*, 8 bit interpreted text, no Endian issue)
POV (Persistence of Visionraytracer*)
RIFF (WAV & AVI*)
TIFF
XWD (X Window Dump*)

Karthik Balaguru

 

[Keith Thompson]

the numbers for a computer are all little endian

[...]

Wrong.

Are you "RoSsIaCrIiLoIA"? If so, apparently you're changing your name
to avoid killfiles. Please stop; it's rude.