LLVM-based toolchain

Well, this is the wishlist forum!

After seeing some of the horrible things Norcroft is doing to my code¹, and realising that most compiled module code is going to be at least partially nasty anyway², and seeing the ugliness of the apparent workarounds that have gone into the NVidia module³, I was thinking that it would be nice if RISC OS was being built by a compiler that wasn’t held back by the limitations of the AOF file format – not to mention the many other problems with Norcroft. Obviously I’m not expecting this to happen overnight, but it would be a “nice to have” once we’ve sorted out the other big wishlist item of getting everything into a state where it can be cross-compiled with GCCSDK. Plus there’s the chance GCCSDK would have moved on to an LLVM-based compiler by then anyway.

¹ A switch statement where each case is of the form ‘return func_XXX();’. If the functions aren’t inlined Norcroft generates a branch/jump table where each entry branches to another branch, and that second branch branches to the function – even though the functions are all defined in the same file as the switch statement, and marked as static. However if the functions are inlined, the branch table jumps straight to the function – but this comes at the cost of the switch() function having the stack footprint of the worst-case function called from within the switch, instead of the nil stack footprint of the un-inlined version.

² Because the compiler has no idea where non-local variables will be stored until link time, each access must involve LDR’ing an offset that’s been written out by the linker. This is rather wasteful when you realise that a significant number of those offsets could be expressed as immediate offsets in the LDR/STR that accesses the target variable.

³ Having the module header written in assembler, banning the use of non-local variables in C, and instead passing around a pointer to a struct containing all the global variables.

LLVM may have a lot of promise for ARM, but that remains to be seen. Anyway, work is slowly underway for latest versions of GCC for RISC OS.

For the sake of clarity, I’m unlikely to do any more GCCSDK/ROOL work until at least summer, if not later. The biggest problem is not actually the C, but the assembler. There’s lots of advanced stuff ‘asasm’ doesn’t handle which objasm makes use of. There are still many C things to fix however, which in aggregate is a lot of manual work.

Anyway, the requirement for a non-free toolchain for ROOL I think is a huge stumbling block for more general take up of OS development.

I’ve just started looking into taking over the ARM frontend for libcpu.org with a view to using it to run some of the norcroft suite. I’ve managed to use libcpu to emulate the BBC micro enough for BBC BASIC 2 to run, which is encoraging.

Hopefully if the tools are nice and use the SharedCLibrary then its just a case of implementing the C api via the SWI calls.

I’ve managed to use libcpu to emulate the BBC micro enough for BBC BASIC 2 to run, which is encoraging.

Shame it’s a completely different instruction set!

As I understand it libcpu’s ARM frontend is still very rudimentary. But if you use decgen with libcpu you’ll at least know who to talk to for help with the instruction set decoder ;)

Yeah i know 6502 is a completely different instruction set but I’d just used it to familiarise myself with libcpu and to get a feel for what is possible with this kind of emulation. Only took me a couple of hours to get that up and going.

I’m planning on taking over the ARM frontend to get it up to speed for RiscOS purposes. Only really need Armv2/Armv3 for Norcroft to run IIRC.