RE: gcc-2.95.2 problem with target powerpc-eabi

RE: gcc-2.95.2 problem with target powerpc-eabi

[David Korn]

>From: Christoph Hirzel [ mailto:hirzel@indel.ch ]
>Sent: 26 October 2000 07:45

>There seems to be a problem in copying 64 Bit integers
>or structures with gcc-2.95.2 for target powerpc-eabi.

>	lis 11,u1@ha
>	la 9,u1@l(11)
>	lis 10,u2@ha
>	la 11,u2@l(10)
>	lfd 0,0(11)
>	stfd 0,0(9)
>
>The compiler seems to optimize the copy by using load (lfd)
>and store (stfd) double float instructions.

  Can I enquire *why* this is a problem? I have the impression (stop me
if I'm wrong) that lfd/stfd will do a straight load/store between the
fpregs and memory, without any messing around with rounding or format
conversion or anything like that.

    DaveK
-- 
SEAL Team 6 World Trade Center Serbian Cocaine [Hello to all my fans
in domestic surveillance] cracking KGB nuclear arrangements CIA
counter-intelligence smuggle fissionable ammunition SDI

RE: gcc-2.95.2 problem with target powerpc-eabi

[Christoph Hirzel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

In our kernel I can create tasks with floating point enabled or
disabled. If I don't need floating numbers in a task I disable them
to improve task switches (much faster because the kernel doesn't
have to save/restore the 32 floating point registers of the PPC603).
So my problem is if I work with 64 Bit integers or stuctures in a
task with floating support disabled this task stops with a floating
point exception.

Christoph

-----Ursprüngliche Nachricht-----
Von: David Korn [ mailto:dkorn@pixelpower.com ]
Gesendet: Donnerstag, 26. Oktober 2000 13:29
An: 'hirzel@indel.ch'; gcc-help@gcc.gnu.org
Betreff: RE: gcc-2.95.2 problem with target powerpc-eabi


>From: Christoph Hirzel [ mailto:hirzel@indel.ch ]
>Sent: 26 October 2000 07:45

>There seems to be a problem in copying 64 Bit integers
>or structures with gcc-2.95.2 for target powerpc-eabi.

>	lis 11,u1@ha
>	la 9,u1@l(11)
>	lis 10,u2@ha
>	la 11,u2@l(10)
>	lfd 0,0(11)
>	stfd 0,0(9)
>
>The compiler seems to optimize the copy by using load (lfd)
>and store (stfd) double float instructions.

  Can I enquire *why* this is a problem? I have the impression (stop me
if I'm wrong) that lfd/stfd will do a straight load/store between the
fpregs and memory, without any messing around with rounding or format
conversion or anything like that.

      DaveK
--
SEAL Team 6 World Trade Center Serbian Cocaine [Hello to all my fans
in domestic surveillance] cracking KGB nuclear arrangements CIA
counter-intelligence smuggle fissionable ammunition SDI


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

gcc-2.95.2 problem with target powerpc-eabi

[Christoph Hirzel]

Hi

There seems to be a problem in copying 64 Bit integers
or structures with gcc-2.95.2 for target powerpc-eabi.
If I compile the following code for a PowerPC 603
(option -mcpu=603)

unsigned long long u1;
unsigned long long u2;

void Test()
{
	u1 = u2;
}

the compiler generates the following assembler code

	lis 11,u1@ha
	la 9,u1@l(11)
	lis 10,u2@ha
	la 11,u2@l(10)
	lfd 0,0(11)
	stfd 0,0(9)

The compiler seems to optimize the copy by using load (lfd)
and store (stfd) double float instructions.

Now my question. How can I avoid this, without using the
compiler option -msoft-float ? 
I think it should be possible if I make some adjustmenst
in the rs6000.md /.c /.h files and then rebuild the compiler.

Has anybody any experience in doing this ?

Thanks

Christoph Hirzel
Tuefiwies 26
CH-8332 Russikon
Switzerland