I have compiled the library for an ARM7TDMI core and it works fine in the ARM simulator, when the simulator is set up to act like an ARM7TDMI (Not surprising...) Sadly the hardware we have is an ARM7DI, it does not have an extened multiply unit and therefore has a baby when we put the code into it.
Tried to force the compiler to compile for an ARM7DI target, but at the end of comilation received a host of errors, all relating to the SMULL instruction, only supported by the TDMI range of cores. (USed the -mcpu=ARM7DI flag in the makefile to set the target platform)
Is there a way to compile the library without incurring the SMULL instructions? I recall something to do with a generic C file that was slower than the optimised assemly, but was platform independant, I just can't remember enough details to dig it out and get it working. Does anyone know anything about this mysterious C file? Many thanks
On Thursday, June 6, 2002, at 07:56 AM, Gareth Bransby wrote:
Is there a way to compile the library without incurring the SMULL instructions? I recall something to do with a generic C file that was slower than the optimised assemly, but was platform independant, I just can't remember enough details to dig it out and get it working.
Try passing --enable-fpm=64bit or --enable-fpm=default to `configure'. The former will give you better accuracy (if it works), but the latter is more portable.
-- Rob Leslie rob@mars.org
I have configured libmad with the option --enable-fpm=default and --enable-fpm=64bit and the compiled with the option --mcpu=arm7di to disable thumb and the enhanced multiply witch our processor doesn't support. The compile fails with the following errors :
Error: bad instruction 'smull r0,lr,r1,r3' Error: bad instruction 'smlal r0,lr,r1,r3'
There are a lot of these errors, and the registers occurring in the statements change. I think these instructions are specific to the extended multiply unit which is why they throw errors when compiling with the ARM7DI as the target, the question is, how to compile without using these instructions and using ARM7DI friendly ones instead?
On Thu, 6 Jun 2002 10:42:38 -0700 Rob Leslie rob@mars.org wrote:
On Thursday, June 6, 2002, at 07:56 AM, Gareth Bransby wrote:
Is there a way to compile the library without incurring the SMULL instructions? I recall something to do with a generic C file that
was
slower than the optimised assemly, but was platform independant, I
just
can't remember enough details to dig it out and get it working.
Try passing --enable-fpm=64bit or --enable-fpm=default to `configure'. The former will give you better accuracy (if it works), but the latter is more portable.
-- Rob Leslie rob@mars.org
I have just had a look and these instructions causing the hassles are all in the file imdct_l_arm.S Is there a c alternative to this that is more portable ?
On Thu, 6 Jun 2002 10:42:38 -0700 Rob Leslie rob@mars.org wrote:
On Thursday, June 6, 2002, at 07:56 AM, Gareth Bransby wrote:
Is there a way to compile the library without incurring the SMULL instructions? I recall something to do with a generic C file that
was
slower than the optimised assemly, but was platform independant, I
just
can't remember enough details to dig it out and get it working.
Try passing --enable-fpm=64bit or --enable-fpm=default to `configure'. The former will give you better accuracy (if it works), but the latter is more portable.
-- Rob Leslie rob@mars.org
Yes - use the --disable-aso configure option.
I have tried configuring with --enable-fpm=arm/default/64bit and --disable-aso but still the asm errors when compiling with -mcpu=arm7di.
One question, why it there a file called imdct_l_arm.s and not any other called imdct_l_mips/sparc/i386/xxx ? Why does arm get its own file ? I thought this was maybe generated by configure but it is there from a fresh untar so this can't be so.
On Thu, 6 Jun 2002, Gareth Bransby wrote:
Yes - use the --disable-aso configure option.
I have tried configuring with --enable-fpm=arm/default/64bit and --disable-aso but still the asm errors when compiling with -mcpu=arm7di.
Look in libmad/Makefile to be sure imdct_l_arm.S doesn't get compiled. Specifically, make sure the ASO variable doesn't contain -DASO_IMDCT and ASO_OBJS is set to nothing.
One question, why it there a file called imdct_l_arm.s and not any other called imdct_l_mips/sparc/i386/xxx ? Why does arm get its own file ?
Because no one provided them. Therefore those architectures default to the C version.
Nicolas
I have searched thorough the amke file and come up with the following :
line 63 ASO = line 64 ASO_OBJS = line 103 INCLUDES = $(FPM) $(ASO)
There is no -DASO_IMDCT anywhere.
So everything seem to be as you say it should be. Any other suggestions ?
What file is this default C version of the assembler in ?
On Thu, 6 Jun 2002 15:44:53 -0400 (EDT) Nicolas Pitre nico@cam.org wrote:
On Thu, 6 Jun 2002, Gareth Bransby wrote:
Yes - use the --disable-aso configure option.
I have tried configuring with --enable-fpm=arm/default/64bit and --disable-aso but still the asm errors when compiling with
-mcpu=arm7di.
Look in libmad/Makefile to be sure imdct_l_arm.S doesn't get compiled. Specifically, make sure the ASO variable doesn't contain -DASO_IMDCT and ASO_OBJS is set to nothing.
One question, why it there a file called imdct_l_arm.s and not any
other
called imdct_l_mips/sparc/i386/xxx ? Why does arm get its own file
?
Because no one provided them. Therefore those architectures default to the C version.
Nicolas
I tried renaming the imdct_l_arm.arm file so it will not be found by the compiler but it still only complains about the bad instructions and not that it can't find the file. The instructions are only in this file so what's going on? The error gives the path to the file, /tmp/ccnuGNEj.s. But, this file does not exist. It is the same after make distclean. Should i be doing a whole untar of the original archive?
On Thu, 6 Jun 2002 15:44:53 -0400 (EDT) Nicolas Pitre nico@cam.org wrote:
On Thu, 6 Jun 2002, Gareth Bransby wrote:
Yes - use the --disable-aso configure option.
I have tried configuring with --enable-fpm=arm/default/64bit and --disable-aso but still the asm errors when compiling with
-mcpu=arm7di.
Look in libmad/Makefile to be sure imdct_l_arm.S doesn't get compiled. Specifically, make sure the ASO variable doesn't contain -DASO_IMDCT and ASO_OBJS is set to nothing.
One question, why it there a file called imdct_l_arm.s and not any
other
called imdct_l_mips/sparc/i386/xxx ? Why does arm get its own file
?
Because no one provided them. Therefore those architectures default to the C version.
Nicolas
On Thursday, June 6, 2002, at 01:06 PM, Gareth Bransby wrote:
I tried renaming the imdct_l_arm.arm file so it will not be found by the compiler but it still only complains about the bad instructions and not that it can't find the file. The instructions are only in this file so what's going on? The error gives the path to the file, /tmp/ccnuGNEj.s. But, this file does not exist. It is the same after make distclean. Should i be doing a whole untar of the original archive?
/tmp/ccnuGNEj.s would be a temporary file created by your compiler, which means your compiler is generating the bad instructions (and your assembler is rejecting them.)
What file is being compiled when this error occurs, and what is the full compiler command line?
Also try the compiler command again, but include the -v switch to see how it is running the assembler.
-- Rob Leslie rob@mars.org
This is the last line before the errors are reported. It seems to be compiling synth.
/home/gar/install/bin/arm-elf-gcc -DHAVE_CONFIG -I. -I. -I. -DFPM_ARM -Wall -O -mcpu=arm7di -fforce-mem -fforce-addr -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizations -fregmove -fschedulue-insns2 -fstrength-reduce -finline-functions -fomit-frame-pointer -c synth.c -o synth.o /tmp/ccYmTbLE.s: Assembler messages: /tmp/ccYmTbLE.s: Error: bad instruction 'smull r4,r7,lr,ip'
On Thu, 6 Jun 2002 14:21:57 -0700 Rob Leslie rob@mars.org wrote:
On Thursday, June 6, 2002, at 01:06 PM, Gareth Bransby wrote:
I tried renaming the imdct_l_arm.arm file so it will not be found
by the
compiler but it still only complains about the bad instructions
and not
that it can't find the file. The instructions are only in this
file so
what's going on? The error gives the path to the file,
/tmp/ccnuGNEj.s.
But, this file does not exist. It is the same after make
distclean.
Should i be doing a whole untar of the original archive?
/tmp/ccnuGNEj.s would be a temporary file created by your compiler, which means your compiler is generating the bad instructions (and your assembler is rejecting them.)
What file is being compiled when this error occurs, and what is the full compiler command line?
Also try the compiler command again, but include the -v switch to see how it is running the assembler.
-- Rob Leslie rob@mars.org
Sorry, that last mail got sent by accident before i was finished with it
I have attatched the output of the compiler when i re ran it with the -v switch. I hope you can make more sense of that than i can!
On Thu, 6 Jun 2002 22:39:09 +0100 Gareth Bransby g.c.bransby-99@student.lboro.ac.uk wrote:
This is the last line before the errors are reported. It seems to be compiling synth.
/home/gar/install/bin/arm-elf-gcc -DHAVE_CONFIG -I. -I. -I. -DFPM_ARM -Wall -O -mcpu=arm7di -fforce-mem -fforce-addr -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizations -fregmove -fschedulue-insns2 -fstrength-reduce -finline-functions -fomit-frame-pointer -c synth.c -o synth.o /tmp/ccYmTbLE.s: Assembler messages: /tmp/ccYmTbLE.s: Error: bad instruction 'smull r4,r7,lr,ip'
On Thu, 6 Jun 2002 14:21:57 -0700 Rob Leslie rob@mars.org wrote:
On Thursday, June 6, 2002, at 01:06 PM, Gareth Bransby wrote:
I tried renaming the imdct_l_arm.arm file so it will not be
found
by the
compiler but it still only complains about the bad instructions
and not
that it can't find the file. The instructions are only in this
file so
what's going on? The error gives the path to the file,
/tmp/ccnuGNEj.s.
But, this file does not exist. It is the same after make
distclean.
Should i be doing a whole untar of the original archive?
/tmp/ccnuGNEj.s would be a temporary file created by your
compiler,
which means your compiler is generating the bad instructions (and your assembler is rejecting them.)
What file is being compiled when this error occurs, and what is
the
full compiler command line?
Also try the compiler command again, but include the -v switch to see how it is running the assembler.
-- Rob Leslie rob@mars.org
Gareth Bransby wrote:
This is the last line before the errors are reported. It seems to be compiling synth.
/home/gar/install/bin/arm-elf-gcc -DHAVE_CONFIG -I. -I. -I. -DFPM_ARM -Wall -O -mcpu=arm7di -fforce-mem -fforce-addr
As far as I remeber, FPM_ARM shouldn't be there... for the Newton port, I used FPM_DEFAULT. It looks like a configuration issue with the Makefile, configure, etc.
Eckhart
That seems to have fixed it. I changed -DFM_ARM to -DFPM_DEFAULT in the makefile and it compiled fine.
So even though i had used the --disable-aso and --enable-fpm=arm options -DFPM was still set to ARM and needed setting to DEFAULT manually
It seems that --enable-fpm-default is not working properly.
Anyway the program runs fine now in armulator set as an ARM7D. We get a funny error message about 'program finished in step' when trying to run it on the board using angel debug. I will try again tomorrow using a multi-ice an see if it is any different.
Thanks for all the help everyone.
On Thu, 06 Jun 2002 15:14:47 -0700 Eckhart Koeppen eck@40hz.org wrote:
Gareth Bransby wrote:
This is the last line before the errors are reported. It seems to
be
compiling synth.
/home/gar/install/bin/arm-elf-gcc -DHAVE_CONFIG -I. -I. -I. -DFPM_ARM -Wall -O -mcpu=arm7di -fforce-mem -fforce-addr
As far as I remeber, FPM_ARM shouldn't be there... for the Newton port, I used FPM_DEFAULT. It looks like a configuration issue with the Makefile, configure, etc.
Eckhart
-- -- eck@40hz.org -- www.40hz.org --
On Thursday, June 6, 2002, at 02:39 PM, Gareth Bransby wrote:
This is the last line before the errors are reported. It seems to be compiling synth.
/home/gar/install/bin/arm-elf-gcc -DHAVE_CONFIG -I. -I. -I. -DFPM_ARM -Wall -O -mcpu=arm7di -fforce-mem -fforce-addr -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -fexpensive-optimizations -fregmove -fschedulue-insns2 -fstrength-reduce -finline-functions -fomit-frame-pointer -c synth.c -o synth.o /tmp/ccYmTbLE.s: Assembler messages: /tmp/ccYmTbLE.s: Error: bad instruction 'smull r4,r7,lr,ip'
That FPM_ARM is undoubtedly what is getting you into trouble. Are you sure you configured with --enable-fpm=default (in addition to --disable-aso)?
-- Rob Leslie rob@mars.org
-
Eckhart Koeppen -
Gareth Bransby -
Nicolas Pitre -
Rob Leslie