Make RISC OS compilable using standard GNU toolchain

How about this?

For at least two or three hours each week for the last 4 weeks I’ve been teaching myself RISC OS programming and have three working additions (the very first of which, a tiny enhancement written in a way I wouldn’t now, I submitted to be included – admittedly it probably wasn’t suitable to be included but it would have been nice to get a reply…) and it’s clear to me that one major thing that will put off almost anyone interested in coding the operating system is the fact that to work on it at some point you are going to have to use very archaic tools.

I don’t think it’s unreasonable, given how reasonably simple it is, that it could be put in a state where with the minimum of faffing around it could be cross compiled using any modern pc with the gnu toolchain.

I also don’t think I really need to explain what the advantages of this would be. They should be obvious.

Is this a feasible bounty to add do y’all think?

Is this a feasible bounty to add do y’all think?

I’m sure one of the RISC OS GCC developers is likely to point out that you can build the IOMD branch with RO GCC. I think that very statement may have been made in these forums.

Is there any documentation on how to build RISC OS using GCC?

Is there any documentation on how to build RISC OS using GCC?

I don’t think there is any as it’s not currently possible. There’s asasm which is a drop in replacement for objasm. I imagine the build system would need major changes to be able to use gcc. Plus there’s the problem of gcc only supporting elf format object files.
Some bits build ok if you create your own make files. RISC_OSLib for example.

I don’t think there is any as it’s not currently possible. There’s asasm which is a drop in replacement for objasm.

Possibly a bit iffy or incomplete? But:

/docs/changes
GCCSDK GCC 4.1.2 Release 1 (released 21 April 2012)
– asasm: significant set of fixes to improve ObjAsm compatibility. Now
able to be used to build ROOL RISC OS 5 IOMD and IYONIX branches.

/docs/asasm/readme
Following persons helped testing and improving the v2.00 release by building
ROOL RISC OS IOMD, IYONIX and OMAP3 branches:

Maybe someone can supply accurate information. Finished or not GCC compiling of ROOL sources is clearly a target.

Maybe someone can supply accurate information. Finished or not GCC compiling of ROOL sources is clearly a target.

The situation is still more or less the same. As far as know no one is working on using gcc as a replacement for the build system.

admittedly it probably wasn’t suitable to be included but it would have been nice to get a reply…)

There’s a pile of work to do. Didn’t somebody write just the other day that their OMAP3 port is still not finished (and the Beagle is how old now?). For submissions, I don’t think we can expect a reply quickly. ;-)

the fact that to work on it at some point you are going to have to use very archaic tools.

Hehe…

Good. I’ve used the VB IDE quite a lot, and also the cumbersome Eclipse setup. I backed out of doing anything for Android because I hated that environment, and pretty much the only thing VB had going for it is a decent way of debugging line-by-line.

I prefer the archaic RISC OS tools because the tools don’t try to interfere, think for me, auto-correct stuff with weird side effects (there’s one in VB that causes the auto-formatter to (silently) mess up names of elements in a structure).

Maybe today’s programmers prefer to have their hands held with IDEs that prompt all the properties and elements available. To my mid, that’s only a few steps above Scratch…

of faffing around it could be cross compiled using any modern pc with the gnu toolchain.

Well, that would offer a speed advantage, yes.

Also “proper” code revision tracking; if necessary. That said, when I make a release of something, I create a directory called “vX.XX” (which reflects the version number) and I copy all the files into that.

Is this a feasible bounty to add do y’all think?

Apparently some builds can be made with GCC. Question is – how? It’s probably a little harder than running a setup script and then choosing a few options in !Builder.

There are various aspects on using the GNU toolchain and other Open Source tools for building RISC OS kernel (I’m not talking about standalone libraries or module building). Currently there is support missing in the build system and probably some innocent changes to the sources are needed as well. It could be that there functionality missing in the current toolchain, I don’t know for sure so that just needs to be investigated and reported. It would be great someone taking up this challenge and I’m happy to support on advice and/or changes in the GCCSDK toolchain for this (free time permitting of course).

First of all, the current Norcroft/ROOL C/assembler toolchain is AOF based. GCCSDK developers decided to start using ELF binary format from GCCSDK 4 onwards, like the rest of the world is using, as continuing supporting AOF is just not the best way to spend our free time on. BTW, there is one exception, asasm (the ObjAsm compatible assembler) can also output AOF.

Speaking of asasm, as said here as well, you can today use it to build the IOMD and IYONIX branches of RISC OS 5 but you keep on using the Norcroft/ROOL AOF linker (and probably other tools as well). The other branches are (I believe) not possible as there isn’t VFP/NEON support in asasm yet.

So the direction for building RISC OS kernel is IMHO:
- Use ELF binary output, so that means the ld linker with a dedicated linker script to link all RISC OS components into the final RISC OS kernel ELF binary (aside this can contain debug DWARF data which you can use for remote debugging via JTAG). I think it is important to upfront investigate and decide how each binary component output is going to be finally linked to one final binary.
- asasm for assembler sources
- gcc for C sources not requiring runtime support, I guess options -nostdinc and -static are needed. The object files produced won’t be relocatable but I don’t think that’s going to be a problem for the RISC OS kernel.
- For RISC OS modules written in C and part of the RISC OS kernel binary, some investigation is needed : I assume you can just build & link them as normal standalone RISC OS modules (use gcc’s -mmodule option) and the result (a RISC OS module) needs to be wrapped in ELF object file again in order to be linked in the final RISC OS kernel binary. However, those modules will at start up let their C runtime branch tables patched by a SharedCLibrary SWI call. This won’t work when the kernel is made read-only, so temporary don’t make the kernel read-only or go for a proper solution (probably based on whatever is done today).
- cmunge for CMHG file processing
- Are there still binary blobs in the current RISC OS kernel ? If so, those will need to be wrapped in an ELF binary (you can use asasm to do this with dummy assembler file doing INCBIN).

BTW, I suggest to use the current GCCSDK trunk version (not yet released, but available for testing), i.e. gccsdk-gcc-bin-4.7.4-Rel1dev.zip at http://www.riscos.info/downloads/gccsdk/testing/4.7.4/ Any technical questions, bug reports, request for advice on the toolchain are better done in the GCCSDK mailing list, see http://www.riscos.info/mailman/listinfo/gcc

There is another aspect as well, this all assumes building on RISC OS itself. One day someone might want to investigate what’s missing to do cross builds (e.g. on a Linux based system). I believe some work for cross building is done but don’t know the details (Ben ?). If that would be feasible (all above mentioned tools are buildable and available on non-RISC OS platforms), builds will be a couple of magnitudes faster.

GCCSDK developers decided to start using ELF binary format from GCCSDK 4 onwards, like the rest of the world is using, as continuing supporting AOF is just not the best way to spend our free time on.

Mmmm… RISC OS != rest of world.
Plus, I wasn’t aware that Windows natively supports ELF.

It seems to me more like “rest of world” means “trying to bend something that isn’t Linux to work the Linux way”. :-)

Mmmm… RISC OS != rest of world.
Plus, I wasn’t aware that Windows natively supports ELF.

This is not a discussion on the binary format used or supported by an OS (BTW, in case of RISC OS, that’s AIF or utility/module format, not AOF), but by available toolchains.

It seems to me more like “rest of world” means “trying to bend something that isn’t Linux to work the Linux way”. :-)

FYI ELF is used by many other OS’s than Linux, Linux just adopted it nearly 20 years ago like others did. Cfr. https://en.wikipedia.org/wiki/Executable_and_Linkable_Format if you want to be more informed.

And also, ELF binary format is what ARM Ltd actually standarized on so on the long run it would make sense to have native RISC OS support for ELF binaries, but that’s a separate discussion.

“It seems to me more like “rest of world” means “trying to bend something that isn’t Linux to work the Linux way”. :-) "
FYI ELF is used by many other OS’s than Linux, Linux just adopted it nearly 20 years ago like others did.

John, I think the problem is there’s a lot of people think anything != RISC OS = bad.
There is in fact a fair bit to e learned from what other OS’s do.

Having said that I think the people responsible for Unity as foisted on Ubuntu users should be sent on a long walk along a short pier.

I think the problem is there’s a lot of people think anything != RISC OS = bad.

Well it is for RISC OS. There’s nothing wrong with other OSs and if I want to use them I use them. I can use them on much nicer machines too.

FYI ELF is used by many other OS’s than Linux, Linux just adopted it nearly 20 years ago like others did.

I know more platforms use ELF. Used it myself in NetBSD for instance. Either way, it isn’t a format native to RISC OS so if gcc isn’t using AOF, how well will it interact with AOF libraries? And the same in reverse. An ELF library or object file isn’t going to be of use to me.

And also, ELF binary format is what ARM Ltd actually standarized on

What, you mean when they left RISC OS waaaay behind and started work with Angel and onwards to flavours of Unix. It would certainly permit greater ease with the host compiler than sticking with a RISC OS specific format.

so on the long run it would make sense to have native RISC OS support for ELF binaries, but that’s a separate discussion.

Should be doable – a bit of code to read the header and load stuff where required… However it’s a little more complicated than that, re. my mixup between ELF binaries and that used internally by the toolchain. ELF is rather more than just an executable file format.

a lot of people think anything != RISC OS = bad.

I think you’ll find I’m not one of them. There are fundamental limitations that cannot be overlooked. For instance, I don’t watch animé on a RISC OS machine…

However, it may be worth pointing out how much of a pain it can be to use something that is ported from a different platform, and resolutely sticks to the conventions of the original platform in preference to preexisting conventions of the platform in question.
To give examples – DOS command line programs which resolutely insist on parameters beginning with a ‘-’ and worse, longer parameters beginning with a ‘—’, in preference to the standard ‘/’ used throughout DOS. Oh, and failing to recognise even ‘/?’. I can only guess that the ‘-’ vs ‘—’ thing has its origins in lazy command line processing.
Command line programs for RISC OS that either expect Unix style paths to be provided, or choke if the file supplied does not have an extension.
Programs for either that refer to media with names like /dev/sda1.
Programs that when called incorrectly (or even just by running the program with no parameters to see if it gives any indication on its usage) just sit there doing nothing. Oh, I lie. It isn’t doing nothing. It is waiting for input from stdin, regardless of whether or not the host operating system is capable of operating in such a manner.

The td;dr version is that this is not a question of whether or not RISC OS is good or bad, or non RISC OS is good or bad; but rather: whether using non RISC OS paradigms on RISC OS is good or bad.

I submitted to be included – admittedly it probably wasn’t suitable to be included but it would have been nice to get a reply…)

Where did you submit to and when? It’s possible it got queued-up over the Christmas break.

Bump.