GCC generating not implemented instructions

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

GCC generating not implemented instructions

2,353 Views
felipe-gm
Contributor II

Hi there,

currently I am developing for a MPC5777 board, with e200z7 cores. Most of the things are going well, but I am stuck with a problem that is really annoying me already.

I am trying to use floating point operations on portions of my code, using the embedded hardware support. My toolchain is GCC 6.3 (powerpc-gcc), for which I am using the following flags:

ASFLAGS_BASE = -g -a32 -mbooke -me500 --fatal-warnings

ARCH_FLAGS    = -mpowerpc-gpopt -mfprnd -misel -m32 -mhard-float -mabi=spe -mmfpgpr -mfloat-gprs=single

Please notice the -mfloat-gprs=single flag. That is the one that is giving problems.

When I use -mfloat-gprs=single, I am not able to compile things properly, as some functions are not implemented:

undefined reference to `__extendsfdf2',

undefined reference to `__adddf3',

undefined reference to `__divdf3',

among others.

Now, if I compile using -mfloat-gprs=double, it goes till the end and generate all my execution files. BUT, using this flag also generates extra functions, not implemented by the e200z7. I can't tell for sure all of them, as the code is getting bigger and it is mostly impossible to track all generated assembly. For instance, at the moment my execution gets stuck when it reaches the efscfd  instruction, which is implemented by the e500 core, that has double precision floating point support, but not for the e200, that has single precision support only.#

So, any piece of advice here would be amazingly welcome!

Thanks in advance,

4 Replies

2,057 Views
felipe-gm
Contributor II

Hi James, thanks for replying.
Indeed, it is not the toolchain provided by NXP and for sure that can be one issue. Nevertheless, as I am not relying on VLE for now, I assumed it would be ok to use my own port of GCC. Extra, I would love not to depend on updates/patches only from NXP, that is why I am forcing my own GCC version.

Anyway, thank you very much for your answer.

0 Kudos

2,057 Views
jamesmurray
Contributor V

I guess it depends on your focus!?

I've previously done some toolchain development, but currently I just want use it.

So as the NXP gcc is generating useable code for me, I would rather leave that alone and work on the device firmware...

James

0 Kudos

2,057 Views
felipe-gm
Contributor II

No argue there. Still, I am not sure I can rely solely on NXP toolchain. I do need to have access to the compiler code. I can go into much details, but there are portions of it that I need to change. I don't think I can do the same with the one provided by NXP

0 Kudos

2,057 Views
jamesmurray
Contributor V

The processor I'm working with is VLE not bookE, but I wonder if you would be better off with the NXP provided toolchain and gcc.

I checked on mine here and it allows -mcpu=e200z7 as an option.

" valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e200z0 e200z2 e200z3 e200z4 e200z6 e200z7 e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le rs64 titan "

I'm using -mvle , but this version (of 'as') still lists -mbooke as an option.

James