error :pmCoreStandby_tz.S:1102: Error: selected processor does not support requested special purpose register -- `msr FPEXC,r4

Am using the tar ball (gcc-arm-none-eabi-4_7-2012q4-20121208.linux.tar.bz) downloaded from the link below

https://launchpad.net/gcc-arm-embedded/+download

It is an issue in binutils (as), not in gcc.

Binutils 2.23.1 had fixed most of them. Unfortunately our release bases on binutils 2.22.

And please double check the "ARM Architecture Reference Manual". Some MSR/MRS should be VMSR/VMRS.

The upcoming release will involve the back port of this fix. Welcome to try again.

@Terry Guo May i know when is the next release ? Or is there a way for me to update the binutils alone to 2.23.1 in the GCC version 4.7.2 ?

Thanks for your valuable reply.

We have quarterly milestone, so if everything goes well, it will be released by the end of March.

Have you read our How-to-build manual and tried to run the build-toolchain.sh script? If so, just replace the binutils source folder with binutils 2.23.1, and then follow the manual to build a new tool chain. This should be a short-term solution. My recommendation is we should wait for the upcoming release because it has been verified and tested.

You could try my bleeding-edge-toolchain, which has the most up-to-date binutils (and not only that) - it's just a variation about the package from here (;

http://www.freddiechopin.pl/en/download/category/11-bleeding-edge-toolchain

Hi Freddie ,

Your Toolchain do not support 32 bit Linux ? Because i cannot see the same in the link that you have shared.

Thanks for your idea/help.

Well, it's not that it "does not support", I just couldn't compile that using the scripts, as my Linux is 64-bit... You can download any package and there are my scripts (which are - of course - modified scripts from the original package), so if you have some free time you'll be able to compile that... I have some ideas for yet another stab at 32-bit Linux version, but I just didn't get down to it - as the Linux I'm using is on a virtual machine, the compilation process is painfully slow and kills my PC (;

Hi,

Even I got the same error while using gcc 4.7 compiler. As Zhenqiang Chen mentioned, Some MSR/MRS should be VMSR/VMRS, When I change MSR/MRS to VMSR/VMRS, no error occurs.

gcc 4.6 doesn't throw this error whereas gcc 4.7 does. I referred to the ARM reference manual and saw the usage of VMRS.

But still, Can I change MSR/MRS to VMSR/VMRS directly to resolve errors? What does this actually mean? Can anyone help?

To add to the above query,

For understanding better, I changed MSR/MRS to VMSR/VMRS and compiled using GCC 4.6. I got the following error.

Error: operand 1 must be FPSCR -- `vmrs r4,FPEXC'
Error: operand 0 must be FPSCR -- `vmsr FPEXC,r6'
Error: operand 1 must be FPSCR -- `vmrs r5,MVFR0'
Error: operand 0 must be FPSCR -- `vmsr FPEXC,r4'

But I expected the following error,

Error: selected processor does not support requested special purpose register -- `vmrs r4,FPEXC'

Can anyone explain?

Actually this is a problem of assembler in Binutils. The MRS/MSR instructions are used to access system registers. There are two kinds of system registers here: one for general core and one for floating point unit. The old assembler hasn't good check on those two kinds of system registers, so it's ok to use mrs/msr to access system/status registers for core or fpu. The correct behavior is we should use VMSR/VMRS to access fpu's system/status registers and MSR/MRS for core's. Such check is added into recent assembler, so you have to use VMSR/VMRS for fpu's system/status register.

Question in #10 is another issue of assembler. Let me answer it later.

Got it. Thank you so much for your quick response.

For question in entry #10, assembler in 4.6 toolchain still has code to limit vmrs to accept only FPSCR register. This is consistent with what ARM reference manual says.

Lately according to review comments at http://sourceware.org/ml/binutils/2013-04/msg00081.html, it's better to remove such limitation on register. So for more recent assembler, the FPEXC is accepted even it doesn't make sense to cortex-m4.

I think currently vmrs accepts all the registers given below. This is given in ARM reference manual.

FPSID
FPSCR
MVFR1
MVFR0
FPEXC

I want to make it clearer, so please comment if you disagree with my below understanding.

From the perspective of recent assembler, vmrs accepts those registers without considering whether they are available on a real arm core. From the review comments in above URL, I think it becomes a programmer's obligation to write correct code.

For a given core like cortex-m4, only register FPSCR is meaningful to vmrs instruction. The others like MVFR0 is optional and implementation defined, they would be implemented as memory-mapped registers in the System Control Block, for example the MVFR0 would be implemented at address 0xE000EF40. So for cortex-m4, the access to MVFR0 requires a memory load instruction rather than the vmrs instruction.

Meanwhile for other cores like a cortex-a profile core, those registers are real system registers, not memory-mapped ones. So they should be accessed through VMRS instructions.

For the "ARM reference manual", I referred to the one for armv7-m and the one for armv7-a.