when i am trying to compile the dhrystone benchmark in riscv-sodor for -march RV32I, an unrecognized opcode 'amoadd' error exits the compilation.
riscv-gcc -m32 -Wa,-march=RV32I -std=gnu99 -O2 -nostdlib -nostartfiles -DPREALLOCATE=1 -DHOST_DEBUG=0 \
-c -I../env -I./common -I./dhrystone ./dhrystone/dhrystone_main.c -o dhrystone_main.o
In file included from ./dhrystone/dhrystone_main.c:12:0:
./common/util.h:11:0: warning: "rdcycle" redefined [enabled by default]
./dhrystone/dhrystone.h:385:0: note: this is the location of the previous definition
/tmp/ccDLKK6P.s: Assembler messages:
/tmp/ccDLKK6P.s:16: Error: unrecognized opcode `amoadd'
make: *** [dhrystone_main.o] Error 1
Is there any way to compile the dhrystone for baremetal hardware of RV32I.
Remove the -Wa,-march=RV32I flag.
-Wa,-march=RV32I is telling the assembler to only accept valid RV32I instructions. It has found an amoadd instruction, so it properly errored out. The assembler is in no position to change out invalid instructions for valid instructions, that's the compiler's job.
Unfortunately, as of 2014 Dec, the riscv-toolchain's gcc port does not yet support -march=RV32I.
Instead, it is on the programmer to personally avoid writing code that will emit multiplies, AMOs, floating point, etc. In fact, the provided dhrystone code includes floating point instructions (I believe only in the initialization code) which would also cause -Wa,-march=RV32I to fail as well. In this situation, the programmer of dhrystone checks whether the processor supports floating point instructions and branches around them as required.
On a more academic note, I believe the amoadd is coming in from the common/util.h's "barrier" implementation. However, since dhrystone does not call barrier, I'm unsure why the assembler is being passed an amoadd instruction. I certainly don't see it in my own disassemblies of dhrystone. I also was unable to reproduce your error on my own RISCV compilers. I am using a riscv-gcc from early August 2014 (https://github.com/ucb-bar/riscv-tools) and a newer gcc4.9 found at (https://github.com/ucb-bar/riscv-tools/tree/new-abi), which is in testing, but will soon be moved to master (~Jan 2015).
Related
I am using crosstool-ng to crosscompile for 68000 (version:crosstool-ng-1.24.0-rc2, host OS:Ubuntu 20.04)
My target is a 68000 (plain, not a 68020 or a cpu with floating point support).
I am compiling using a test program which multiplies two floats, using
-m68000 -mcpu=68000 -msoft-float -Wall -fno-builtin -O2
However, when I execute it, I get illegal instruction error
(notice, this happens only if I use floats)
Suspecting newlib is targeting 68020, I tried adding
CT_LIBC_NEWLIB_TARGET_CFLAGS="-m68000 -msoft-float"
but that made no difference.
What am I doing wrong? Do I need some code in the illegal instruction handler?
I am getting an error with gcc(7.2.0) and also pgi(18.4) compilers.
There is a scientific application (in fortran) that I am compiling that has some dependencies.
These dependencies are compiled with -fPIC flag.
While compiling the main application, I get an error "relocation truncated to fit".
When I add the flag -mcmodel=medium(pgi), the compilation succeds.
But I am not willing to add this flag for some reasons.
Also when I compile the main application with -fPIC, i get linker error and a suggestion to add --no-relax flag.
After adding the same, I still get the relocation error.
Is there any way I can compile without the -mcmodel=medium flag?
Edit:
Also, when using gnu compilers, whatever mcmodel I use, I am getting the relocation error. Can this be something related to an old linker. Because I think, the application and its dependencies are compiled with 64 bit libraries, and the linker is what I assume operates with 32 bit libraries. As a reason for successful compilation with pgi when I perform /ld-linux.so --list , I get an error saying cannot map to zero fill pages. And while running the executable, I get a message as Killed.
I found out that the ARM-compiler armcc V5.05 does not compile uint64_t correctly into assembly code. It uses only one register instead of two so the result is truncated to 32 bits (though the compiler is not complaining).
As a workaround I used the gcc compiler, put the generated assembler code into a separate asm file and ran the ARM assembler. The target could not be created due to the error:
This register combination results in UNPREDICTABLE behaviour
which is really fatal, I suppose. After the C- "return" statement at the end of a function gcc inserts an offending SUB SP,R11,#0 or ADD SP,R11,#0 command before the ASM-return command BX LR. This is true with or without uint64_t.
Can I rely on gcc or is it a bug in armcc/armasm?
I am compiling a C file using the gcc flag -ffunction-sections, to move every function into it's own section. The assembler is throwing the error:
job_queue.s:2395: Error: operation combines symbols in different segments
The compiler's assembly output at line 2395 is given here:
.section .debug_ranges,info
.Ldebug_ranges0:
.4byte .LBB7-.Ltext0
The symbol LBB7 is in the function (and thus the section) named ".text.add_event_handler"
The symbol Ltext0 is in the (otherwise empty) section named: ".text"
GCC --version gives:
pic30-elf-gcc.exe (GCC) 4.0.3 (dsPIC30, Microchip v3_30) (B) Build date: Jun 29 2011
If I use the compiler flag -g0 (to turn off debug info) everything compiles and runs perfectly.
My question:
Is this GCC output clearly wrong? It seems to me that GCC should have calculated the symbol LBB7's offset from the beginning of the .add_even_handler section instead of the .text section.
I suspect I am misunderstanding something because I cannot find anyone having the same difficulty on the Google.
The GCC output is definitely wrong. Perhaps it's fixed in newer GCC versions. If you can't upgrade you compiler, try compiling with -gdwarf-2 or, failing that, with -gdwarf-2 -gstrict-dwarf (for -gstrict-dwarf you'll have to upgrade the compiler too).
What this option does is to instruct GCC to generate (strict) DWARF2, which does not include non-contiguous address ranges support, introduced in DWARF3.
Of course, this may degrade the debugging information quality somewhat, YMMV.
Is it (easily) possible to use software floating point on i386 linux without incurring the expense of trapping into the kernel on each call? I've tried -msoft-float, but it seems the normal (ubuntu) C libraries don't have a FP library included:
$ gcc -m32 -msoft-float -lm -o test test.c
/tmp/cc8RXn8F.o: In function `main':
test.c:(.text+0x39): undefined reference to `__muldf3'
collect2: ld returned 1 exit status
It is surprising that gcc doesn't support this natively as the code is clearly available in the source within a directory called soft-fp. It's possible to compile that library manually:
$ svn co svn://gcc.gnu.org/svn/gcc/trunk/libgcc/ libgcc
$ cd libgcc/soft-fp/
$ gcc -c -O2 -msoft-float -m32 -I../config/arm/ -I.. *.c
$ ar -crv libsoft-fp.a *.o
There are a few c files which don't compile due to errors but the majority does compile. After copying libsoft-fp.a into the directory with our source files they now compile fine with -msoft-float:
$ gcc -g -m32 -msoft-float test.c -lsoft-fp -L.
A quick inspection using
$ objdump -D --disassembler-options=intel a.out | less
shows that as expected no x87 floating point instructions are called and the code runs considerably slower as well, by a factor of 8 in my example which uses lots of division.
Note: I would've preferred to compile the soft-float library with
$ gcc -c -O2 -msoft-float -m32 -I../config/i386/ -I.. *.c
but that results in loads of error messages like
adddf3.c: In function '__adddf3':
adddf3.c:46: error: unknown register name 'st(1)' in 'asm'
Seems like the i386 version is not well maintained as st(1) points to one of the x87 registers which are obviously not available when using -msoft-float.
Strangely or luckily the arm version compiles fine on an i386 and seems to work just fine.
Unless you want to bootstrap your entire toolchain by hand, you could start with uclibc toolchain (the i386 version, I imagine) -- soft float is (AFAIK) not directly supported for "native" compilation on debian and derivatives, but it can be used via the "embedded" approach of the uclibc toolchain.
GCC does not support this without some extra libraries. From the 386 documentation:
-msoft-float Generate output containing library calls for floating
point. Warning: the requisite
libraries are not part of GCC.
Normally the facilities of the
machine's usual C compiler are used,
but this can't be done directly in
cross-compilation. You must make your
own arrangements to provide suitable
library functions for
cross-compilation.
On machines where a function returns
floating point results in the 80387
register stack, some floating point
opcodes may be emitted even if
-msoft-float is used
Also, you cannot set -mfpmath=unit to "none", it has to be sse, 387 or both.
However, according to this gnu wiki page, there is fp-soft and ieee. There is also SoftFloat.
(For ARM there is -mfloat-abi=softfp, but it does not seem like something similar is available for 386 SX).
It does not seem like tcc supports software floating point numbers either.
Good luck finding a library that works for you.
G'day,
Unless you're targetting a platform that doesn't have inbuilt FP support, I can't think of a reason why you'd want to emulate FP support.
Doesn't your x386 platform have external FPU support? Pity it's not a x486 with the FPU built in!
In my experience, any soft emulation is bound to be much slower than its hardware equivalent.
That's why I finished up writing a package in Ada to taget the onboard 68k FPU instead of using the soft emulation provided by the compiler manufacturer at the time. They finished up bundling it in their compiler as a matter of fact.
Edit: Just seen your comment below. Hmmm, if you don't need a full suite of FP support is it possible to roll your own for the few math functions you do need? That how the Ada package I mentioned got started.
HTH
cheers,