Who'll do the "da Vinci" workstation, then?

If somebody is seriously imagining writing a new OS, then for the love of everything beautiful, do the job correctly!

Something I’ve given a little thought to – with the assumption that 64-bitting will break compatibility anyway – is the concept of finding an existing Linux distribution that’s similar-ish to RISC OS from a UI perspective, then tweaking that until we have something resembling the current UI. But I haven’t got very far down this track, not least because I’m struggling to find a distro that isn’t riddled with bugs.

Oh my god. Assembler to C translation will result in an unmaintainable clustermew that only has a passing resemblance to C.
You need to work out what the code is actually doing and write that algorithm, not a literal translation from assembler to C.

Perhaps you think I mean machine translation? No. If it would be clearer to call it a rewrite rather than a translation, I’m OK with that. But yes, understand what it’s doing and then write that in C.

But if we do create RISC OS 64, it has to be compatible with RISC OS 5. Otherwise you’d have to create all the apps from scratch too.

I agree that it cannot be the same at register level, but (for example) a call to OS_GBPB must still require the same parameters, in equivalent places, so that BASIC calls to SYS look the same, and C call to _swix (or your preferred equivalent) look the same, etc.

If you don’t maintain a very high level of compatibility, you might as well not bother, because you’ll have nothing to run on it. Just run Linux and be done with it.

If you don’t maintain a very high level of compatibility, you might as well not bother, because you’ll have nothing to run on it. Just run Linux and be done with it.

That being the entire crux of the matter.

I looked into the RISC OS sources this afternoon. The first module I looked at was Desktop. It’s not very big. It must be a candidate for an experiment in translation. I didn’t see the machine instructions as undule difficult. What threw me, and it does it every time I look at this sort of stuff, is the assembler directives. But I do think it’s do-able.

I’d really appreciate a re-write of GSTrans/SetVarVal/ReadVarVal written in such a way that it copies the strings (or numbers, or code) into malloc’d blocks of memory. No need for memory management or GSInit/GSRead. I should be able to re-factor that into a multi-processor friendly implementation.

This is as far as I got yesterday (just reading the PRMs):

Types of variable returned from read: 0 String, 1 Number, 2 Macro
 
Types of variable for setting:
  0 String to be GSTrans'd immediately when setting the variable
  1 Number (4 bytes, signed)
  2 String to be GSTrans'd when the variable is read (Macro)
  3 Expression to be evaluated immediately (resulting in number or string)
  4 String that will not be GSTrans'd when setting the variable or reading it
 16 Code (a code fragment that will be executed to read/write the variable)
 
OMG, you can use wildcards in set operations!
 
Wildcards are a problem, there will have to be a flag indicating that a
variable was just found and may be used in another OS_SetVarVal call.
 
Maybe keep a list of current wildcard searches and return a reference to the 
next matching node in the tree. Something like that.
 
TODO:
  Set literal string variable
  Read string variable
  Set number variable
  Read number variable
  Set macro variable
  GSTrans a string containing no variables
  GSTrans a string containing variables
  Read a macro variable

I’d really appreciate a re-write of GSTrans/SetVarVal/ReadVarVal

I’m wondering if this wouldn’t be a good time to start a discussion regarding splitting this sort of thing out of the kernel into it’s own resource, so the kernel can be exactly that, rather than an MOS ROM-like pile of “useful routines” all jumbled together (OMG, OS_Byte…).

It’s a move the other branch did decades ago.

Absolutely. The system variables first, please, (everything uses them) and the whole GSInit/GSRead approach is horribly thread unsafe.

Absolutely. The system variables first, please, (everything uses them) and the whole GSInit/GSRead approach is horribly thread unsafe.

Nemo joined the discussion last night, taking about his work on Unicode. He mentioned that system variables can already contain unicode, but the variable names cannot. While re-writing GSTrans it would be good to rectify this.

Wouldn’t it be better to create a new thread in WishList for the changes to GSTrans/SetVarVal/ReadVarVal?

Just my 0.5c

Let’s all give credit to Julie for having made a start on rewriting RISC OS in C.

https://www.riscosopen.org/forum/forums/2/topics/17601

I was talking to a friend last night and he asked whether I’d tried out a new “AI” of some description. I scoffed and replied “wake me up when it can convert Arm assembly to C”. At that he copied some random code from GitLab:

StartPumpStartROMApps Entry
        LDR     r14, nactive            ; don't start unless this was first task
        TEQ     r14, #0
        BNE     %FT50

        MOV     r0, #ReadCMOS
        MOV     r1, #DeskbootCMOS
        SWI     XOS_Byte
        EXIT    VS

        MOV     r3, r2
        MOV     r1, #Deskboot2CMOS
        SWI     XOS_Byte
        EXIT    VS
        AND     r2, r2, #bootbits_mask :SHR: 8
        ORR     r2, r3, r2, LSL #8      ; r2 = full flag word

        ADRL    r3,bootcommands

        STR     r2, PumpParams_0
        STR     r3, PumpParams_1

        ADR     r0, PumpOneStartROMApp
        STR     r0, NextPump
        B       %FT01

PumpOneStartROMApp ALTENTRY
01
        LDR     r2, PumpParams_0
        LDR     r3, PumpParams_1
10
        MOVS    r2, r2, LSR #1          ; is next bit set?
        BNE     %FT20
        BCC     %FT50                   ; EQ and CC, ie no more commands to activate
20
        ADD     r1, r3, #1
        LDRB    r14, [r3]
        ADD     r3, r3, r14
        STR     r2, PumpParams_0
        STR     r3, PumpParams_1
        BCC     %BT10
 [ debugtm
        MOV     r14, r0
        SWI     XOS_ReadMonotonicTime
        Push    "r0,r14"
        MOV     r0,r14
 ]

He doesn’t understand assembly so he didn’t realise that he didn’t have a full “block”. Despite that, it produced the following C:

int nactive;

void StartPumpStartRAMApps()
{
    if (nactive != 0)
        return;

    int r0 = ReadCMOS;
    int r1 = DeskbootCMOS;
    int r2 = XOS_Byte(r0, r1);
    int r3 = r2;
    r1 = Deskboot2CMOS;
    r2 = XOS _Byte(r0, r1);
    r2 = (r2 & bootbits_mask) >> 8;
    r2 |= r3 << 8;
    r3 = bootcommands;
    PumpParams_0 = r2;
    PumpParams_1 = r3;
    NextPump = &PumpOneStartROMApp;
    PumpOneStartROMApp();
}

void PumpOneStartROMApp()
{
    int r2 = PumpParams_0;
    int r3 = PumpParams_1;

    do
    {
        if ((r2 & 1) == 0)
            return;

        r1 = r3 + 1;
        r14 = r3[0];
        r3 += r14;
        PumpParams_0 = r2;
        PumpParams_1 = r3;
        r2 >>= 1;
    } while (r2 != 0);

    XOS_ReadMonotonicTime(r14);
}

Sure, it’s not perfect, but I was surprised by how much it “understood”. I wonder whether this could feasibly be used as a starting point for C-ification.

Dangerously bad, isn’t it?

Obviously you’d need to figure out what each bit’s doing and e.g. rename variables (r0, r1, etc. help nobody), but at least it’s in a format that I (and other C users) can understand now. I’ve tried to read bits of assembly and have ended up totally confused, but after that machine translation I have an inkling of what’s going on.

I’m certainly not suggesting that the verbatim output is any good as-is :)

I know people say that C is like a high level assembler, but this is just extracting urine…

@ Chris

that type of “direct” translation is something that debuggers like IDA do by long time and the IDA decompiler does a better job than that.

I have been experimenting extensively with AI models, but it’s a waste of time at the moment. The specific requirements for writing RISC OS Kernel code in C are way to hard to be used to generate an ML Model to train a neuronal network of any form and shape. They can however work well for user-space code and for languages like Python or Lua (I had some success with training an AI to write BBC BASIC code).

The other problem is that supervised training is a total pain with kernel code, because (among all the details you need to take care of) you need an environment that can be fully controlled to detect all code mistakes and machine crashes in order for the model to improve.

It would appear that quite a few people, maybe 5-6, are working separately to port RISC OS from assembler to C. Individualism is fine, but in this case – why not cooperate, split the task into parts to ensure that no time is wasted on two or more programmers working on the same code. Maybe Github could host such a project, with the most experienced person as project manager? Just a thought.

are working separately to port RISC OS from assembler to C.

Several people are doing work to convert some parts of RISC OS to C.

Nobody is doing all of it.
And I would imagine without changes to the runtime, the use of C in the kernel will remain minimal.

Maybe Github could host such a project

Are you not aware of this?

That being said, I’d like to draw attention to this.
Does Julie’s Obey rewrite in C work, or not? Because it looks like the Obey that’s in ROM is still the assembler version, and Julie’s version is from two years ago… so…?

AFAIK, I’m the only one trying to re-implement the underlying kernel to provide threading and multi-processing. I am not re-writing the OS_Plot code, for example, just using the existing code.

I anticipate objections to my approach to implementing a HAL. It’s also still to be seen if the interrupt model works well.

It might not be popular, but a lot easier to convince people if it works than if it doesn’t!

I anticipate objections to my approach to implementing a HAL.

I always maintain that informed, constructive criticism is fine.
Everything else, well…

I always maintain that informed, constructive criticism is fine.

Fixed that for you. Seems far too many people just want to whinge about stuff, all too often in the context of “I’m right and you’ll never be”. ¹ Especially when they’re demonstrably not right.

As I get older, I’m more and more inclined to want to glue pillows to the wall so I don’t hurt myself smacking my head against a solid object.

I anticipate objections to my approach to implementing a HAL.

The usual best answer to that is “feel free to do better”.

It might not be popular

Or it might be a lifeline. Who knows?

a lot easier to convince people if it works than if it doesn’t!

Can’t argue that. ;)

¹ Recent comment topic on El Reg – vaccinations and mask wearing. Oh my…

“I’m right and you’ll never be”.

RISC OS – (arguably) never was right and never will be ;-)

Does Julie’s Obey rewrite in C work, or not?

I think I mentioned her RAMFS port to C somewhere recently too.

Doesn’t fill anyone with enthusiasm to do similar work, does it?

quite a few people, maybe 5-6, are working separately to port RISC OS from assembler to C

OK, let’s have a poll. Who is actively writing replacement modules for existing RISC OS assembler components in C?

Not me.

Lets dismiss the idea of directly translating existing assembler to C right now, it is a pointless waste of time to use C as a macro assembler. There are far better automated just or ahead of time translators which can turn 32 bit ARM in to 64 bit ARM or AMD64 or whatever.

The point of re-writing in C is to express the idea of what the code is doing in as higher level human readable way as possible, to make it easier to maintain, enhance and debug. It should make things like adding new APIs easier, allowing data types to changed to a larger number of bits, or to ad local storage and locks for multiprocessor support.

Translating assembler does none of that, a fresh implementation from a functional specification is the only way to achieve those aims.

a fresh implementation from a functional specification is the only way to achieve those aims

I agree – but I wonder how hard it would be to get a consensus on such a spec – how much ancient stuff can be junked?

And again, it boils down to money. It’s too large a project for a volunteer effort.

The future for RISC OS on AArch64 is emulation. I like having a whizzy little Pi etc. but would happily settle for RPCEmu on Linux (and don’t really care what architecture that’s running on) when the native hardware dies.

Are you . aware of this?

No, I was not. It doesn’t appear to be very active, however. Last activity from 3 moths back; most between 1-3 years. No indication as to when it’ll be done that I found. Should one be optimistic?

It doesn’t appear to be very active

Perhaps this https://www.riscosopen.org/viewer/events helps?

Should one be optimistic?

A pessimist is rarely disappointed.

Don’t get me wrong – I really love RISC OS. I’m very happy that it’s been dragged kicking and screaming into the 21st Century. But we have to realise its serious limitations and that some ‘dreams’ are simply beyond scope.