Linking extASM with GCC

The following may be of interest to some…

The current version of the extASM assembler only handles production of “raw” binaries, as well as AOF object files (with extAOF), which means that files produced by it can’t be linked with later versions of GCC, which now uses the ELF format.

However, lately, I’ve done some tests, “manually” producing ELF executables and object files using extASM source code, and successfully linked the latter to a program written using C/C++.

Ideally, it should be possible to do this directly in GCC, using inline assembly, but as I understand, the current RISC OS version doesn’t yet support the newer ARM instructions, like VFP/NEON.

Therefore, if anyone would like to experiment with writing e.g. VFP/NEON code, and link it with C/C++, there is a possibility for that with extASM now, as long as you don’t mind editing the files producing the ELF files “manually”.

I’ve put up some example files with instructions, here.

About six months ago we made GCCSDK GCC 4.1.2 Rel1 available for testing purposes (http://www.riscos.info/pipermail/gcc/2010-July/005325.html) using binutils 2.20.1 allowing to process assembler files with NEON/VFP and linking with your C/C++ code.

The current trunk version is atm even using binutils 2.21 (a month or so old).

And now speaking of assemblers, it might be interesting to know that currently a lot of effort is being put into ASASM (formally known as AS) to be an OpenSource ObjAsm/RealView clone with AOF/ELF output which could be a useful stepping stone to cross-compile RISC OS code base and offer a migration path from AOF to ELF on the longer term (http://www.riscos.info/websvn/listing.php?repname=gccsdk&path=2Ftrunk%2Fgcc4%2Friscos%2Fasasm%2Fx%x#ae0332fdbb56b5b8c1a0812b6ec7ede74). The basic framework is now a bit better than it was before and ready to be enhanced with the ARM v6/v7 instructions. Feel free to contact me or the gccsdk mailing list if you want to help.

And to finalize, the gcc 4.6 port we have in development is able to target the latest ARMv7 architecture (with NEON/VFP if wanted).

About six months ago we made GCCSDK GCC 4.1.2 Rel1 available for testing purposes (http://www.riscos.info/pipermail/gcc/2010-July/005325.html) using binutils 2.20.1 allowing to process assembler files with NEON/VFP and linking with your C/C++ code.

Excellent, I’ll give it a go when I get home.

I’ve now tried assembling the following instruction with both GAS and ASASM of the GCC 4.1.2 version mentioned above, but neither of them accept it:

VADD.I8 Q0,Q1,Q2

Am I doing something wrong?

For GAS you need to specify which FPU you want to address. So in this case e.g. -mfpu=neon is needed. Other option values are `fpa’, `fpe2’, `fpe3’, `maverick’, `vfp’, `vfpv3’, `vfpv3-fp16’, `vfpv3-d16’, `vfpv3-d16-fp16’, `vfpv3xd’, `vfpv3xd-fp16’, `neon’, `neon-fp16’, `vfpv4’, `vfpv4-d16’, `fpv4-sp-d16’ and `neon-vfpv4’ but I believe some, vfpv4 ones, are only supported in binutils 2.21.

ASASM is not yet NEON/VFP aware.

Thanks, but unfortunately, it still doesn’t work… I’ve even tried adding ”-march=armv7-a”, as well as other -mfpu values, but it made no difference.

I tested this by modifying the GAS example included with GCC, and executed both the modified makefile, and the following command:

gcc asm_gas.s -mfpu=neon

Neither of the following instructions were recognised (comments were not included):

VADD.I8 Q0,Q1,Q2    @ NEON
VADD.F32 S0,S1,S2   @ VFP

Could you have done a test?

And now speaking of assemblers, it might be interesting to know that currently a lot of effort is being put into ASASM (formally known as AS) to be an OpenSource ObjAsm/RealView clone

I don’t normally like to pre-announce things, but I’ve been quietly working away in the background for some months to update objasm to be closer to the RealView assembler as well, so there’ll soon be a wide selection of v7 assemblers to choose between – though I’m still unaware of anyone offering to update the BASIC assembler.

Any chance that this new version of asasm will actually be able to assemble the RISC OS source code? The last time I tried it, it choked on most of the source files I tried it with.