Re: GCC and Hitachi H8300h (floating point problem) #2

[Michael Portmann <mikep@adelaide.on.net>]

At 09:20  13/05/99 +0200, you wrote:
>Hello,
>
>I have problem with floating point numbers. Look at following
>example:

  so have we.

>
>void main()
>{
>    float x = 1.0;
>.....
>}
>
>Constant value of "1.0" are located in ".rodata"
segment. 
>In the linker script I use the following line:
>
>.text 0x00041000 : { *(.text) *(.rodata); }
>
>After program linking in program code I see processor
instructions
>to load value from memory at correct displacement from beginning
>of ".text" segment, but WITHOUT 0x00041000 OFFSET?
Why???
>I tried to write:
>
>.text      0x00041000 : { *(.text); }
>.rodata 0x00048000 : { *(.rodata); }

  What we have found is the compiler is generating source code with
an instruction that
loads the register with the local constant defined storage (is this the
correct term?) for the
floating point value. The address access gets appending with a
:16..  so it ends up chopping
the high order byte of the address and gets it arse up (a 16 bit address
access "tiny" shouldn't
require those higher order bits!) but this is wrong - it should be
accessing it as normal - ie 24 bits
on the H8S.

  If you globally define the float value, ie  

float ONE=1.0;

main()
{
 float x=ONE;
}

The correct code is generated.

Looking at the source code for egcs 1.2, we noticed that the only way
possible (to our knowledge)
that the :16 could be placed in the assembly would be if one of the prior
intermediary files had an
& in front of the variable - which it does not, so I don't know where
the :16 is coming from.

Anyone ?? !!    - We're going to just recompile the egcs
sources to stop it producing any :16 references
and thus temporarily remove our problem - we shall see what happens. (I
don't think we are able to get
the compiler to do any tiny data accesses - or even eight bit accesses
where we want since, 
from memory, this has never been generated due to us making the registers
volatile. - so no :16
references won't harm us much - if at all.)

BTW all this stems from us wanting to use the pow() functions which do
define "local constants" in the
newlib source code - and of course being compiled with the egcs compiler
for the H8S, generates the
wrong code.

Regards,
Michael Portmann.



_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.