ROOL C/C++ - Useful for other ARM targets?

Hi,

Bit of a noob question here but I was wondering whether the C/C++ Dev kit can be used for writing non-RISCOS software, such as for embedded microcontrollers.

I have the dev kit but also am trying to move from PIC 8-bit microcontrollers to 32-bit ARM devices and was wondering if the dev kit can compile/assemble pure ARM machine code without the RISCOS-specific headers, etc.

If that is the case, surely that is a gap in the market considering how much a professional ARM development suite costs!

Cheers
Simon.

I don’t see why not. The C compiler has an -l option to specify libraries (instead of the default), plus link offers the following:

*link -h
ARM Linker Version 5.27 [07 Oct 2002]

Command format: link [options] object_file1, object_file2 ...

General options (abbreviations shown capitalised):
-Output file       Put final output in 'file'
-Debug             Include debugging information in image
-ERRORS file       Put diagnostics to 'file', not stderr
-LIST file         Put Map and Xref listing to 'file', not stdout
-VIA file          Take more object file names from 'file'
-Verbose           Give informational message while linking
-MAP               Print an area map to the standard output
-Xref              Print an area cross-reference list
-Symbols file      List symbol definitions to 'file'
-Symdefs file      Update/create SYMDEFS definition file 'file'

Output options:
-AIF               Absolute AIF (the default)
-AIF -Relocatable  Relocatable AIF
-AIF -R -Workspace nnn     Self-moving AIF
-AOF               Partially linked AOF
-BIN               Plain binary
-BIN -AIF          Plain binary described by a prepended AIF header
-IHF               Intellec Hex Format (readable text)
-SPLIT             Output RO and RW sections to separate files (-BIN, -IHF)
-SHL file          Shared-library + stub, as described in 'file'
-SHL file -REENTrant   Shared-library + reentrant stub
-RMF               RISC OS Module
-OVerlay file      Overlaid image as described in 'file'
-ELF               Executable and Linking Format
-ELF -Partial      Partially linked ELF output

Special options:
-RO-base n
-Base    n         Specify base of image
-RW-base n
-DATA    n         Specify separate base for image's data
-Entry   n         Specify entry address
-Entry n+obj(area) Specify entry as offset within area
(prefix 'n' with & or 0x for hex; postfix witk K for *2^10, M for *2^20)
-Case              Ignore case when symbol matching
-MATCH n           Set last-gasp symbol matching options
-FIRST obj(area)   Place 'area' from object 'obj' first in the output image
-LAST  obj(area)   Place 'area' from object 'obj' last...
-NOUNUSEDareas     Don't eliminate AREAs unreachable from the AREA 
                       containing the entry point (AIF images only).
-Unresolved sym    Make all unresolved references refer to 'sym'.
-rescan            Rescan libraries to fix up unresolved references.
-C++               Support C++ external naming conventions.

I have not written anything in C or used libraries, but I have used the dev suite in assembler to write a small file for my ARM926 based PVR, plus I tried a simple startup MLO replacement for the Beagle xM (didn’t work, but given the board fails to boot, this doesn’t surprise me much).

I don’t know, ultimately, how useful it would be in practice, but the opportunity is certainly there. If I had to write something in ARM, I’d have no hesitation to use the dev suite as I know I can take the benefits of the assembler and linker, and end up with a raw lump of code at the end of it.

It should be possible. The main issue is that you get no standard C library support. No printf(), no strcmp(), not even simple things like toupper(). Don’t use divide, because that’s a library call too (or write that library function yourself). Floating point might get tricky (no sin() etc). Something like newlib or dietlibc might be interesting but you’d have to make them compile under Norcroft.

It will depend on whether you can get Norcroft to output code compatible with the target platform. This includes the allowed instructions, register usage, perhaps stack alignment. For integer only work, the -apcs, -cpu, etc. options may be able to do this; FP is likely to be more troublesome, I can’t comment on this.

If you are writing really low level stuff where there is nothing else to link against, then this isn’t really an issue, assuming there are no FP problems.

I have a little project which involves building ROM image (no C library or FP), which will build with Norcroft cc/objasm/link or gcc/asasm/ld. So far I’ve only needed to implement functions for division (__rt_udiv10() and __rt_udiv()) when using Norcroft, presumably gcc links in its own equivalents.

It’s actually pretty useful as different tool chains often pick up different issues. The only problem is that I can’t easily use inline assembler in C; Norcroft and GCC have different syntax. Pity, as I prefer Norcroft’s inline assembler to GCC’s but will probably end up having to write both.

I too would be interested to see whether Norcroft or GCC could be used for embedded development. I’ve got a little LPC1114 project under way at home. Currently I use the IAR Embedded Workbench under Wine under Linux. The setup has its foibles, but it’s free.

The LPC1114 is a Cortex-M0, so it is very simple. It might be a good start towards trying Norcroft/GCC.

Clearly the requirements include: do not make any RISC OS calls; allow the programmer to specify locations of the various segments, one of which is based at 0.

I have used the dev suite in assembler to write a small file for my ARM926 based PVR

Indeed – my BBC micro ARM7TDMI coprocessor is assembled with ‘objasm’ and linked with ‘link’ with appropriate switches to output a binary with no AIF headings.

The LPC1114 is a Cortex-M0, so it is very simple. It might be a good start towards trying Norcroft/GCC.

Similarly – my BBC micro ethernet interface (based around an LPC2106) is compiled with GCC 3.4.6r3. You need a handful of dummy functions (like __gcc_main) which I wrote in assembler, but otherwise it’s perfectly possible to output a binary for such a microcontroller using RISC OS as the editor/enviroment. As noted, when calling library functions (including implicit ones like a structure copy might infer memcpy) you have to write the library function yourself, or find a suitably cut down C library in source format.

Your mileage may vary with a Cortex-M family, since Norcroft doesn’t output Thumb code, and GCC’s Thumb2 output was quite buggy (when I last looked, in 2009).