Re: hpgcc arm doubles in memory

On Jan 13, 10:31 pm, Claudio Lapilli <pleasedonts...@xxxxxxx> wrote:
It's not so common, I don't think a lot of people are aware of this,
and it's very strange but that's how the gcc
compiler for ARM treats doubles: (2) 32-bit words stored in big-endian
format. I ran across this issue when trying to implement direct
conversion of 'doubles' to calculator reals.

That's just what I was experimenting with.

If the ARM processor is set in big endian mode,
you would have a "true" big-endian representation.

I noticed this by compiling with -mbig-endian -save-temps and looking
at the assembly .s file.

This is a very weird behavior that should have been avoided (maybe a
compiler switch to use either fully little endian or fully big-endian
but not this mix).

Sounds to me like it was more of an ARM issue than a gcc issue. If I
understand correctly, the optional ARM floating point hardware had
this mixed-endian behavior. The linux gcc arm compiler produces code
that it uses this hardware if available and emulation if it is not, so
that the same executable can run on both machines. This requires gcc
to follow ARM's word order convention. Although I suppose if you knew
it was always going to be emulated, you could do whatever you wanted
with the word order.

It reminds me of the 8088/286/386 days when the 8087/287/387
coprocessors where optional. The MS-C compiler had options to
generating code which either:
a) required the coprocessor
b) used the coprocessor if present and emulated it if not present
c) used a faster non-coprocessor-compatible software code

(I remember the day I put a 287 coprocessor in my 286-10MHz screamer
-- fractals had met their match.)

-wes
.

Relevant Pages

  • Re: [ANN] LBW 0.1: Linux Binaries on Windows
    ... gcc doesn't produce brilliant ARM code --- ... C/C++ compiler) you can see just how much room for improvement there ... Other compiler bugs I've found were mostly in very ...
    (comp.unix.programmer)
  • Re: LPC900/80C51 Compiler Toolchain
    ... The short answer is 'No' - you can't use any GCC version beyond 2.9. ... Gcc 2.9x for the ARM was very poor, ... compile them to assembler source first. ... With modern compilers, there is seldom good reason for hand-optimising your assembly unless you are taking advantage of specific features that your compiler is unaware of. ...
    (comp.arch.embedded)
  • Re: [ANN] LBW 0.1: Linux Binaries on Windows
    ... gcc doesn't produce brilliant ARM code --- if you compare it with ... recompiling their code with RVCT produced a 30% improvement in frame rate. ... The least bad commercial compiler I ever dealt with was for a deeply ...
    (comp.unix.programmer)
  • [2.6 patch] Documentation/arm/README: small update
    ... gcc 3.3 seems to be a good choice on ARM ... The kernel will report an error if your compiler is ...
    (Linux-Kernel)
  • Re: IDE for Atmel ARM processor
    ... > It's hard to believe this, all our tests show that GCC produces almost ... ARM compilers, and Thumb code produced by GCC is *larger* than ARM ... code produced by the ARM compiler... ... In many compilers all optimizations ...
    (comp.arch.embedded)