Bounty proposal: 64-bit CPU support

@ROOL. Let’s open a new bounty for the people interested in a 64-bit RISC OS. ;) It would demonstrate a commitment and provide another signpost to the future of RISC OS.

It a harmless suggestion. I recall a Yes Minister episode where the Minister felt that sponsoring a quango would achieve something. His PS put him wise that none of the quangos achieved anything and the Minister’s response was to kill them all off. His attention was then diverted to a crisis.

There is the problem, though, that well-meaning folks would put money towards it.

There is the problem, though, that well-meaning folks would put money towards it.

Set minimum entry to the bounty at one million quid.

I’ll put £25 towards it, if and only if others put up a million between them – actually, make that half a million. Might be worth a shot even with only half a million.

Let’s open a new bounty for the people interested in a 64-bit RISC OS. ;) It would demonstrate a commitment and provide another signpost to the future of RISC OS.

The planning signpost you’ve already spotted is on the 6 roadmap topics identified as being significant (both in the sense of being big, and also in the sense that doing them would move the dial for RISC OS rather than treading water). The expectation is that by doing the planning stage you then have an understanding of what shape the task takes and ways to break it down into more manageable chunks rather than swallow it whole.

The bounty scheme as it stands works well for things which are of the weeks/months magnitude of engineering and can be reasonably well defined, but the overall task for 64 bit is clearly N years magnitude.

So I think what we’ll more likely see is a list of tasks which can be bounded and delivered, and may well benefit the 32b world today as well. An example off the top of my head might be rewriting BASIC in a HLL & adding 64b integer support (overlaps slightly with an extended BASIC) as you’ll need both of those things in a 64b world, but they’re also useful on 32b ARMs.

Thread resurrection alert.

I emailed ROOL about this a few weeks ago but something has gone astray somewhere and I am not in receipt of a reply.

I’m just a user, but recognise that 64bit is necessary for the long-term future. I’m looking at donating but I want my money to be going towards 64bit (and/or multi-threading). Since there’s no 64bit bounty I don’t know how to achieve this. Is there a resource that a normal user could understand that would indicate which bounties are part of that effort?

I would imagine that ‘64-bit’ is a work item that would absolutely dwarf any of the current bounties. So have a look at the larger (in terms of money) and ask yourself if you are able and willing to donate some soft of multiple of that amount. Perhaps then it would be possible to buy some ‘ROOL time’, and/or contract out some work.

Since there’s no 64bit bounty I don’t know how to achieve this. Is there a resource that a normal user could understand that would indicate which bounties are part of that effort?

Appreciate your helpful response, but this is what I am really looking for. The 64bit problem is clearly going to be broken into smaller problems, as the other bounties are – the proper way to do things in computing anyway. The question remains which ones belong to the 64bit effort. For example, the filer work is, I presume, from the mention of 64bit.

I presume, from the mention of 64bit.

No, that’s 64 bit object addresses, to allow for really big files and really big discs… something that isn’t possible at this point.

(same reason you can’t put a 6GB video on to a FAT32 stick)

The 64bit problem is clearly going to be broken into smaller problems

The 64 bit problem pretty much involves rewriting huge parts of the OS and, personally, I think it would be a massive mistake/missed opportunity to think of doing that, but keeping the same underlying API (that is tied hard to the way the original 26/32 bit processors work).

I’m really not sure “a bounty” would even begin to cover it. Maybe if you pick the right numbers on Euromillions and don’t mind funnelling a lot of that into development costs, then maybe it can happen…

If we want RISC OS to live on as the OS we are all familiar with, maybe there should be a bounty for some sort of emulation that’s just a mite newer than “it’s a RiscPC”?

Indeed, there are many ‘64-bit’ things that could usefully be done right now to use on current 32-bit systems. Accessing files >4GB as Rick mentions, and 64-bit integers in (a different flavour of) BASIC.

It would be handy if one of the Arm machines could be made to go from 64 to 32bit and back.

Or perhaps a emulator that could achieve the same.

That’s relatively easy, the 32 bit code runs in a non-secure environment given a chunk of memory. Getting 40 year old programs to play ball is another matter.

As I understand both RISC OS Open and RISC OS Development Ltd. are working in some way to make 64bit RISC OS possible as they both work on RISC OS to convert ARM assembler code into C/C++.
But they work their way down from the top to the bottom. So until we can see some RISC OS running in 64 bit is some years or centuries away.
So to speed things up I think the work should start from the bottom with a new 64bit kernel. As I understand Simon Willcocks is working on a RISC OS kernel in C. This might be a base for a 64bit RISCO OS kernel.
But I didn’t look into the details of the specifications.
“Simon Willcocks RISC OS Kernel in C:”https://github.com/Simon-Willcocks/RISC-OS-Kernel-in-C
ROOL bounties are stuck also somehow as it appears they have funding sometimes but nobody who can do the task (or already occupied with current bounties).

There could be different stages of 64bit kernel:
1. 1-to-1 copy of current RISC OS kernel functionality
2. RISC OS kernel with multithreading
3. RISC OS kernel with memory protection/virus protection
4. RISC OS kernel with preemtive multitasking with emulator for the 32 bit programs

I will open soon a Patreon to support RISC OS development that is not covered by ROOL or RISCOS Dev.
As I am keen to have 64bit RISC OS that could be one task to work on that (maybe in cooperation with Simon).

What could possibly go wrong…

That’s interesting. Because I’m thinking of starting a scheme to support RISC OS development that’s not covered by ROOL, ROD or Cloverleaf.

If people could just email me their bank details, I’ll take out what I consider an appropriate amount each month.

Thanks in advance, I know the RISC OS community is so supportive.

So to speed things up I think the work should start from the bottom with a new 64bit kernel.

Why? How having a kernel without any modules could help speed up the process?

If people could just email me their bank details, I’ll take out what I consider an appropriate amount each month.

:)

I’ve taken a step back from what I was doing, starting from the ground up again, in the hopes of a more solid foundation now I think I know what’s required to keep legacy code happy. (Basically, there is are small stacks for each core and each mode, and one big one that gets passed around whoever thinks they’re the only player in a RISC OS system; new modules will run in usr32 mode and provide services.)

SimpleAsPi (it doesn’t do any more than blink some external LEDs, at the moment.)

There’s some old 64-bit code to manage a 32-bit environment here, but it’s years old now, and quite strange!

IsambardOS

@Simon Willcocks
Good efforts! I will try to contact you sometime. Any hint how is best way?

email is fine, my dot name at gmx dot de (if you can crack the cunning code!) Or via GitHub, especially for issues.