Re: LittleEndian

Re: LittleEndian

[Robert Dewar]

> Why would you want such an option?  If the code contains byte-order
> dependencies, it's unlikely that a compiler option would fix it.  If you're
> trying to port binary data files, good luck.


Most often the reason people want this is that they think it will automatically
solve the endianess problem in porting code or data from one machine to another.
That's wrong of course, but people live in hope :-)

Re: LittleEndian

[Allan Sandfeld Jensen]

On Monday 29 April 2002 23:52, Robert Dewar wrote:
> > Why would you want such an option?  If the code contains byte-order
> > dependencies, it's unlikely that a compiler option would fix it.  If
> > you're trying to port binary data files, good luck.
>
> Most often the reason people want this is that they think it will
> automatically solve the endianess problem in porting code or data from one
> machine to another. That's wrong of course, but people live in hope :-)

Sometimes it just practical if you want to retain your bitfidling algorithms 
from one architecture to another. Ofcouse personally I would prefer to have 
it as a syntax option to int. E.g. "little_endian long int" or just "le 
long". The ELF-flag would then just specify which is default.

The above would make it possible to mark the places in the code where you 
assume endianness, and as a minimum halt compilation on architectures that 
doesnt support the assumed endian.

`Allan

Re: LittleEndian

[Toon Moene]

Allan Sandfeld Jensen wrote:

> Sometimes it just practical if you want to retain your bitfidling algorithms
> from one architecture to another. Ofcouse personally I would prefer to have
> it as a syntax option to int. E.g. "little_endian long int" or just "le
> long". The ELF-flag would then just specify which is default.

Why do you want syntax to determine endianness ?  Surely it's detectable
at run time.

Here's the Fortran implementation:

      SUBROUTINE ENDIANP
      INTEGER*1 IBITS(10)
      LOGICAL LITTLE
      COMMON /ENDIAN/ LITTLE
      EQUIVALENCE (IBITS, JBITS)
      NWBITS = BIT_SIZE(JBITS)
      NBBITS = BIT_SIZE(IBITS(1))
      DO I = 1, NWBITS, NBBITS
         IBITS(I/NBBITS+1) = I
      ENDDO
      LITTLE = .TRUE.
      KBITS  = JBITS
      DO I = 1, NWBITS, NBBITS
         LITTLE = LITTLE .AND.
     ,               IAND(KBITS,2**NBBITS-1) .EQ. IBITS(I/NBBITS+1)
         KBITS = ISHFT(KBITS, -NBBITS)
      ENDDO
      END

In the routines where you need to know enddiannes, simply declare the
COMMON block:

      ....
      LOGICAL LITTLE
      COMMON /ENDIAN/ LITTLE
      ....
      IF (LITTLE) THEN
         ... ! Little endian branch
      ELSE
         ... ! Big endian branch
      ENDIF
      ...

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: LittleEndian

[Allan Sandfeld Jensen]

On Tuesday 30 April 2002 22:30, you wrote:
> Allan Sandfeld Jensen wrote:
> > Sometimes it just practical if you want to retain your bitfidling
> > algorithms from one architecture to another. Ofcouse personally I would
> > prefer to have it as a syntax option to int. E.g. "little_endian long
> > int" or just "le long". The ELF-flag would then just specify which is
> > default.
>
> Why do you want syntax to determine endianness ?  Surely it's detectable
> at run time.
>
Because it is less code and more elegant. You write one function with one 
endianness. System that has a different can then simultate it, or simply use 
the right one if they support both, like most does by now.

Re: LittleEndian

[Toon Moene]

Allan Sandfeld Jensen wrote:

> Because it is less code and more elegant. You write one function with one
> endianness. System that has a different can then simultate it, or simply use
> the right one if they support both, like most does by now.

Sure - I hope everyone gets it right for a Canadian Cross, then.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: LittleEndian

[Robert Dewar]

> The above would make it possible to mark the places in the code where you 
> assume endianness, and as a minimum halt compilation on architectures that 
> doesnt support the assumed endian.

Any architecture can support either endianness in the weak sense of
supporting it for loads/stores. I agree with the utility of being
able to mark individual declarations. We did this in Realia COBOL
(COMP-4 was big endian, IBM compatible, COMP-5 was little endian,
Intel compatible, and a compiler flag determined whether plain
COMP was COMP-4 or COMP-5).

LittleEndian

[Miri]

Hi,

I’m trying to port code from SUN-Solaris (Sparc) to  Linux using GCC 3.0.4.
I tried to compile  to littleEndian using –mlittle-endian – but its seems
that the new compiler not supports that option (writes that its not in spec
file).

Can you please help or give me a hint.

Thank you

Miri

Re: LittleEndian

[Tim Prince]

On Monday 29 April 2002 00:06, Miri wrote:
> Hi,
>
> I?m trying to port code from SUN-Solaris (Sparc) to  Linux using GCC 3.0.4.
> I tried to compile  to littleEndian using ?mlittle-endian ? but its seems
> that the new compiler not supports that option (writes that its not in spec
> file).
>
> Can you please help or give me a hint.
>
> Thank you
>
> Miri
Why would you want such an option?  If the code contains byte-order 
dependencies, it's unlikely that a compiler option would fix it.  If you're 
trying to port binary data files, good luck.
-- 
Tim Prince

Re: LittleEndian

[Allan Sandfeld Jensen]

On Monday 29 April 2002 17:03, Tim Prince wrote:
> On Monday 29 April 2002 00:06, Miri wrote:
> > Hi,
> >
> > I?m trying to port code from SUN-Solaris (Sparc) to  Linux using GCC
> > 3.0.4. I tried to compile  to littleEndian using ?mlittle-endian ? but
> > its seems that the new compiler not supports that option (writes that its
> > not in spec file).
> >
> > Can you please help or give me a hint.
> >
> > Thank you
> >
> > Miri
>
> Why would you want such an option?  If the code contains byte-order
> dependencies, it's unlikely that a compiler option would fix it.  If you're
> trying to port binary data files, good luck.

Because sparc supports both endians, and the ELF format already contains the 
necessary infomation to protect against wrongfull linking.