| Author |
Message |
Motaz K. Saad
Guest
|
 Posted:
Wed Mar 02, 2005 11:34 pm Post subject:
big-edian & little-endian |
|
|
hi every body
i wrote a c languge program ti determine ur machine whether big-edian
or little-endian,
and i tried it on my machine (little-endian machine),
can any one please try it on big-edian machine and email me the result.
thanx.
here is the program:
/****************************************************************/
/***************************************************************************
* Copyright (C) 2005 by Motaz K. Saad
*
* motsad@yahoo.com
*
*
*
* This program is free software; you can redistribute it and/or
modify *
* it under the terms of the GNU General Public License as published
by *
* the Free Software Foundation; either version 2 of the License, or
*
* (at your option) any later version.
*
*
*
* This program is distributed in the hope that it will be useful,
*
* but WITHOUT ANY WARRANTY; without even the implied warranty of
*
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
*
* GNU General Public License for more details.
*
*
*
* You should have received a copy of the GNU General Public License
*
* along with this program; if not, write to the
*
* Free Software Foundation, Inc.,
*
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
***************************************************************************/
/*This program is valid for 32bit machine*/
/*You can adapt it for 64bit machine*/
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
unsigned int var = 0xff333300;//declare & intialize unsigned 32bit
integer
unsigned char * cPtr;//declare an unsigned byte (8bit)
void * ptr;
/******************************************************************/
//test if the machine is 32bit
if ( sizeof(int) != 4)
{
printf("This program is valid for 32 bit machine only.\n");
printf("Press return to exit...");
getchar();
return EXIT_FAILURE;
}
/******************************************************************/
ptr = &var;//save the start address of the integer
cPtr = ptr;//let a byte (8bit) type pointer point to the start address
/******************************************************************/
/*test if the start address point to the least signficant byte*/
if ( (*cPtr) == 0x00 )
printf( "Your Machine is LITTLE-ENDIAN\n");//if so, it's LITTLE-ENDIAN
/******************************************************************/
/*test if the start address point to the most signficant byte*/
if ( (*cPtr) == 0xff )
printf( "Your Machine is BIG-ENDIAN\n");//if so, it's BIG-ENDIAN
/******************************************************************/
printf("Press return to exit...");
getchar();
return EXIT_SUCCESS;
}
/****************************************************************/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Motaz Khalid Saad.
My Personal WebSite:
http://www.geocities.com/motsad
E-Mail: motsad@yahoo.com
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ |
|
| Back to top |
|
 |
Terje Mathisen
Guest
|
| Posted:
Thu Mar 03, 2005 12:32 am Post subject:
Re: big-edian & little-endian |
|
|
Motaz K. Saad wrote:
| Quote: | hi every body
i wrote a c languge program ti determine ur machine whether big-edian
or little-endian,
and i tried it on my machine (little-endian machine),
can any one please try it on big-edian machine and email me the result.
|
Many such programs have been written previously, some of them probably
better than yours. :-)
Some points:
1) There's no need to make it 32-bit only, or even power-of-two limited.
2) You should be able to determine strange variations as well, such as
DEC 'middle-endian' which is a combination of little-endian 16-bit words
and big-endian 32-bit doublewords (or the opposite?).
3) Casting pointers between void, char and int really doesn't need to
work the way you think it should. :-(
I believe a union of int and array of char might give you better odds of
working on more cpus/compilers.
This doesn't mean that I haven't written pretty much equivalent (to your
program) code myself. :-(
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Goran Larsson
Guest
|
| Posted:
Thu Mar 03, 2005 2:38 am Post subject:
Re: big-edian & little-endian |
|
|
In article <1109788440.565377.315870@o13g2000cwo.googlegroups.com>,
Motaz K. Saad <motsad@yahoo.com> wrote:
| Quote: | //test if the machine is 32bit
if ( sizeof(int) != 4)
|
The comment and the if statement does not match. The if statement
tests if the int type of the machine has 4 * CHAR_BIT bits, not if
it has 32 bits. Also, even if the int type of the machine is 32 bits
the test will not find this, for example, if CHAR_BIT is 16 or 32.
--
Göran Larsson http://www.mitt-eget.com/ |
|
| Back to top |
|
|
Ricardo Bugalho
Guest
|
| Posted:
Thu Mar 03, 2005 4:02 am Post subject:
Re: big-edian & little-endian |
|
|
On Wed, 02 Mar 2005 20:32:42 +0100, Terje Mathisen wrote:
| Quote: |
3) Casting pointers between void, char and int really doesn't need to work
the way you think it should. :-(
|
| Quote: | I believe a union of int and array of char might give you better odds of
working on more cpus/compilers.
|
Unions don't have to work either. Reading from an union element that
wasn't the last to be written to is undefined.
I think that using memcpy is the correct way.
--
Ricardo |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Mar 03, 2005 5:01 am Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen wrote:
| Quote: | This doesn't mean that I haven't written pretty much equivalent (to
your
program) code myself. :-(
|
Does anyone use the rpc/xdr.h functions/macros anymore? I thought they
were supposed to solve these kinds of problems. In the very least
you'd be able to use them to determine the correct ordering for a
possibly more efficient implementation (as in an x86 bswap or ppc
lwbrx) if need be.
As you point out, there are more than big and little endian...3412,
ouch.
#define LITTLE_ENDIAN 1234 /* least-significant byte first (vax)
*/
#define BIG_ENDIAN 4321 /* most-significant byte first (IBM,
net) */
#define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long
(pdp) */
....byte ordering can vary in floats/doubles too, which is something
that I haven't seen much mention of either.
-t |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Thu Mar 03, 2005 7:57 am Post subject:
Re: big-edian & little-endian |
|
|
bybell@rocketmail.com wrote:
| Quote: | Terje Mathisen wrote:
This doesn't mean that I haven't written pretty much equivalent (to
your
program) code myself. :-(
Does anyone use the rpc/xdr.h functions/macros anymore? I thought they
were supposed to solve these kinds of problems. In the very least
you'd be able to use them to determine the correct ordering for a
possibly more efficient implementation (as in an x86 bswap or ppc
lwbrx) if need be.
As you point out, there are more than big and little endian...3412,
ouch.
#define LITTLE_ENDIAN 1234 /* least-significant byte first (vax)
*/
#define BIG_ENDIAN 4321 /* most-significant byte first (IBM,
net) */
#define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long
(pdp) */
....byte ordering can vary in floats/doubles too, which is something
that I haven't seen much mention of either.
|
I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
Terje
PS. One of the uglier things I've seen was in Novell's hack&slash
version of NetworkTimeProtocol (NTP) as used to sync all servers in a
Novell Directory Server (NDS) tree:
They borrowed the big-endian layout of the two 32-bit words in the
64-bit (32:32 fixed-point) integer timestamps, but kept each half in x86
little-endian format.
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Guest
|
| Posted:
Thu Mar 03, 2005 10:35 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
| Quote: | I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
|
Does the `middle-endian' PDP-11 FP count?
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be. |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Thu Mar 03, 2005 11:37 pm Post subject:
Re: big-edian & little-endian |
|
|
In article <87is48r5s9.fsf@prep.synonet.com>, <prep@prep.synonet.com> wrote:
| Quote: | Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
Does the `middle-endian' PDP-11 FP count?
|
It was so on one of DEC's Unices, but I can no longer remember which.
It had to be one of VAX, MIPS or Alpha and Ultrix, DEC/OSF (or any
of its following names).
It wasn't hard to deal with, once I realised. And I was testing a
program to read IBM MVS magnetic tapes, including most of the standard
formats and binary data (including converting floating-point to IEEE).
So I think that I hit most issues :-)
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
toby
Guest
|
| Posted:
Fri Mar 04, 2005 4:36 am Post subject:
Re: big-edian & little-endian |
|
|
Motaz K. Saad wrote:
| Quote: | hi every body
i wrote a c languge program ...
/******************************************************************/
ptr = &var;//save the start address of the integer
cPtr = ptr;//let a byte (8bit) type pointer point to the start
address
/******************************************************************/
/*test if the start address point to the least signficant byte*/
if ( (*cPtr) == 0x00 )
printf( "Your Machine is LITTLE-ENDIAN\n");//if so, it's
LITTLE-ENDIAN
/******************************************************************/
/*test if the start address point to the most signficant byte*/
if ( (*cPtr) == 0xff )
printf( "Your Machine is BIG-ENDIAN\n");//if so, it's BIG-ENDIAN
/******************************************************************/
|
Those dazzling lines of asterisks completely obscure the code for me.
Maybe I am getting old.
I'll pick one other stylistic issue at random: the comments on the
printfs are redundant.
|
|
| Back to top |
|
|
Jan Vorbrüggen
Guest
|
| Posted:
Fri Mar 04, 2005 7:56 am Post subject:
Re: big-edian & little-endian |
|
|
| Quote: | That would be VAX, and I believe the format was kept with Alpha,
and may have originated on the PDP-11.
|
It did originate on the PDP-11.
| Quote: | VAX is little endian for fixed point. Floating point is
big-endian by 16 bit words, where the words are little endian.
(Unless it is the other way around.)
|
That order is correct. All DEC machines are little-endian. When
FP was added to the PDP-11, a 16-bit architecture, I believe the
rationale was to keep the little-endian design for the mantissa
and exponent, but to make the first word contain the sign and
exponent fields, and therefore also the mantissa's MSBs. It does
make sense when you need to do two memory fetches for the whole
value. The VAX-11, as the extended PDP-11, kept the arrangement
for compatibility reasons. The Alpha supports both the VAX FP
layout as well as the IEEE layout.
Jan |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Fri Mar 04, 2005 7:56 am Post subject:
Re: big-edian & little-endian |
|
|
glen herrmannsfeldt wrote:
| Quote: | Terje Mathisen wrote:
(snip)
I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
That would be VAX, and I believe the format was kept with Alpha,
and may have originated on the PDP-11.
VAX is little endian for fixed point. Floating point is
big-endian by 16 bit words, where the words are little endian.
(Unless it is the other way around.)
To initialize a floating point value with a hex value in
VAX Fortran, the digits must be arranged in this strange order.
|
Ouch!
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Terje Mathisen
Guest
|
| Posted:
Fri Mar 04, 2005 7:56 am Post subject:
Re: big-edian & little-endian |
|
|
prep@prep.synonet.com wrote:
| Quote: | Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
Does the `middle-endian' PDP-11 FP count?
|
I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
For something like generating a starting value for a reciprocal square
root, with the exponent patched into a base dual binade lookup table
value, this would make it significantly slower.
Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Fri Mar 04, 2005 7:56 am Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen wrote:
(snip)
| Quote: | I'd _really_ hate to see an implementation where byte ordering was
different for fp and integer values!
Has this ever occured?
|
That would be VAX, and I believe the format was kept with Alpha,
and may have originated on the PDP-11.
VAX is little endian for fixed point. Floating point is
big-endian by 16 bit words, where the words are little endian.
(Unless it is the other way around.)
To initialize a floating point value with a hex value in
VAX Fortran, the digits must be arranged in this strange order.
-- glen |
|
| Back to top |
|
|
D. J. Bernstein
Guest
|
| Posted:
Fri Mar 04, 2005 1:41 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen wrote:
| Quote: | This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
|
float fromlittleendian(char in[4])
{
float magic = 3.8204714345e-37;
float result;
0[(char *) &result] = in[0[(char *) &magic]];
1[(char *) &result] = in[1[(char *) &magic]];
2[(char *) &result] = in[2[(char *) &magic]];
3[(char *) &result] = in[3[(char *) &magic]];
return result;
}
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago |
|
| Back to top |
|
|
Niels Jørgen Kruse
Guest
|
| Posted:
Fri Mar 04, 2005 1:54 pm Post subject:
Re: big-edian & little-endian |
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
| Quote: | I did mention that one. No, it only counts when/if an integer and fp
value with the same number of bits use different bit/byte ordering.
This would make it impossible to write portable code to generate fp
bitpatterns on the fly, you'd be forced to go via library code instead.
|
That is not portable anyway, as there are different FP formats.
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in