Bounty Proposal: Make DDE Open Source

If RISC OS is to continue as a platform, and get the most amount of ports and contributions it can, it only makes sense to have open and free tools to do so. The opening of DDE would facilitate more tools for better ports and better apps (which RISC OS very much needs), therefore, I propose this as a bounty.

The bounty goal could be the amount of money estimated that opening this code would lose (on its own, you could still sell it with ePIC, and you could still sell binaries)

This is very unlikely as ROOL don’t own the source to the C compiler, it belongs to ARM (AFAIK). The time, paperwork and money needed to unravel this could be better spent elsewhere.

However making it free to download might be possible and would be a major step forward.

Steve Revill of ROOL did say they were looking into making the DDE freely available, and could see a way forward, but I haven’t seen or heard of anything since he last spoke about it ~12 months ago.

Perhaps as Bryan suggested, it might be a binary only free download.

Hopefully, ROOL will provide more details about it at the London Show later this month.

This is very unlikely as ROOL don’t own the source to the C compiler, it belongs to ARM (AFAIK).

I seem to recall a different company name (which totally escapes me at present). In the same info I believe Steve R did mention possibly doing something with a variant of the ARM compiler instead.

Might’ve been Codemist. If I recall correctly, it no longer exists.

Might’ve been Codemist. If I recall correctly, it no longer exists.

That’s the one. If we’re both remembering correctly then yes no longer in the business but the owners of the copyright are difficult to communicate with and they don’t know about the old product base.

Norcroft wasn’t it?

I did take a (very vague) look into llvm, wondering if it could be made to generate AOF. So far it emits an AOF header, but I’ve not spent long on it other than adding the bits to accept target “arm—aof” and some debug print statements :)

I guess it would be 32-bit only, but is that actually a big deal?

I guess it would be 32-bit only, but is that actually a big deal?

32bit only output? Maybe. ROOL still support as far back as ARMv2. We need 32bit ARMv3 support for the IOMD ROMs (not sure if LLVM supports that far back out-of-the-box), the boot sequence is 26/32bit neutral (and can be used on ARMv2 if you’re insane), and there are some support modules which can be loaded on ARMv2 machines (most notable C one probably being the shared C library).

Of course, since LLVM is often seen as the holy grail of compiler backends, I’m guessing it wouldn’t be too hard to add an “old ARM” target that sticks to the ARMv2/ARMv3 instruction set (including FPA) and can output 26bit-friendly code.

Or we could take the approach of “use the old compiler if you need support for old machines, otherwise use the new compiler”, which might not be too bad.

ARMv2 and ARMv3 are mentioned in the source, to it might be able to generate code for them.

I can try .. although I should try to get it to emit some code at all first :)