The Future of DTP, Illustration and general GFX/Audio using RISC OS desktop computers (Is 64-bit!)

Or since it’s open source, rely on a similar quantity with identical skill set from within the RISC OS tribe

You seem to overestimate the size of the RISCOS tribe, and/or the percentage of it that has the necessary skill set. Not to mention the existence of benefactors with enough money to provide that insufficient number with the means to survive while they do all the work.

All to what end? Sure, Windows and MacOS aren’t perfect. Linux isn’t perfect. But any of them is capable of doing the things we want computers for, albeit not always quite in the way we’d like. But the effort required to change that is out of all proportion to the possible benefits.

Did I say “possible”? Silly me.

>> Or since it’s open source, rely on a similar quantity with identical skill set
>> from within the RISC OS tribe

> You seem to overestimate the size of the RISCOS tribe, and/or the percentage of it
> that has the necessary skill set. Not to mention the existence of benefactors with
> enough money to provide that insufficient number with the means to survive while
> they do all the work.

We’re back to that “no people, no money” phenomenon again, only with the project at hand multiplied in complexity and to boot, a (shrinking) Tribe which makes the level of impossibility very high re. RISC OS 64. It would appear that the only hope would be pensioned Tribesmen- and women possessing the necessary skills to do it. But then what? Who’ll be there to carry on development, keeping the platform viable? This doesn’t look good.

> All to what end? Sure, Windows and MacOS aren’t perfect. Linux isn’t perfect.
> But any of them is capable of doing the things we want computers for, albeit
> not always quite in the way we’d like. But the effort required to change that
> is out of all proportion to the possible benefits.

The imperfections of W./MOS are the least worries re. those platforms. And Linux (kernel) has accumulated a raft of bugs, some serious, and support for obsolete hardware that it’s approaching bloatware. From this angle the situation could be worse, since writing a new RISC OS 64 kernel would benefit from not having any ballast apart from lots of incompatible legacy software (which could be emulated with probably good results). Starting out afresh would be beneficial in the sense there would be a continuation of the RISC OS platform. The least challenge may be to maintain the user interface as it is, from a user perspective.

> Did I say “possible”? Silly me.

Or not. Once 64-bit, the RISC OS core will be (potentially; in theory!) applicable to billions of 64-bit Arm CPUs. And with the GUI, a super-productive UI running on some rather fast CPUs. Using emulated programs at first, then depending on the Tribe having a revival, natively written software doing even better. That’s what could be, provided the obvious were in place which it isn’t. And reading https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/neoverse-v1-platform-a-new-performance-tier-for-arm it’s quite a way to go.

Once 64-bit, the RISC OS core will be (potentially; in theory!) applicable to billions of 64-bit Arm CPUs.

RISC OS in its 32bit form was already potentially applicable to billions of 32bit ARM CPUs. It even got ported to the RPi, arguably the most successful (non-phone) ARM platform ever.

And yet, RISC OS did not achieve a significant breakthrough. And the technology gap to the rest of the offerings was narrower 10 years ago.

The ugly truth is that RISC OS and the software it runs are just not good enough. It was good in 1990, average in 1995, far below average in 2000, and it got much worse since then. Of course there are still niches where it is a valid choice (see this thread for various examples – one niche is “I’m used to it and won’t change anymore”), but these are getting smaller and less viable year by year.

I haven’t been very active in this thread as it’s big and scary :)

Putting 64-bit aside for now, it would still be good (in my opinion) to get more of the assembly code across to C. I’d love to help… but I don’t know much Arm assembly. I read this series when it was published, and although it’s written from a Windows perspective I still understood most of the explanations and appreciated the annotated code with C equivalents shown.

For example, in part 3, the following line is Greek to me: ldr r0, [r1, r2, lsl #2]!

However, the listed C equivalent, r1 = r1 + (r2 << 2); r0 = *r1;, is understandable. In theory I could use a reference like this to go through assembly line-by-line and convert it to C. Sure, introducing better variable names and native C flow control would be a great help, but I suspect that theoretically you could still C-ify the code with the odd goto and then refactor it once you have it working.

The problem I’ve run into is the “non-code” parts, for want of a better term. If I look at existing assembly then I see things like Push "r0-r2, r14" at the start of “functions” and an associated Pull at the other end. If I understand correctly then that’s the sort of thing that C gives you “for free” (since variables have local scope by default). However, there are similar arcana that I have no idea about. Text seems to be stored independently via DCB but I’m not sure how that works. Looking at the source to PhotoFiler, for example, near the top of one of the files we have:

DCB     "PhotoFilerIgnore", 0
ALIGN
DCD     command_fsreject
DCD     &00010001

I don’t have the foggiest what this is doing, and therefore I don’t know how to convert it to C.

What I’m trying to say in a rather roundabout way is that it would be a great to have a guide that explains some of this stuff in a way that’s accessible to people who are familiar with C but not with Arm assembly. Does anyone know whether such a document already exists?

An interim idea could be to wrap everything in C functions and then use __asm with the existing code, swapping functions one by one. I’m not sure how practical that is though…

Chris – if you want to produce a module in C use the cmhg tool. If you want to produce a filing system there is an example from Acorn. You can find example code of both on my website.

DCB “stuff”,0

is putting a C style string into memory, tacking a zero byte on the end

ALIGN

get back to writing on a 4 byte boundary

DCD command_fsreject

putting the address of a function into memory – veneers are usually needed for C (see the example file system code). A veneer being some code that matches C functions to the entry and exit conditions of a module entry point.

DCD &0010001

putting some data into memory, modules and the like typically have flag bits.

I am suggesting that you can’t convert everything by looking at the assembler and writing the C equivalent. Sometimes adopt the alternative approach, write a skeleton module in C with the appropriate entry points and flags and name strings, and then inject into that the assembler version code.

I suspect that theoretically you could still C-ify the code with the odd goto and then refactor it once you have it working.

That isn’t porting code to C, that is using C as a macro assembler. The refactoring is the important part – turning it in to comprehensible and maintainable C code – and that is easier to do directly from the original assembler source code, than an intermediate C representation which no one is familiar with.

Similar to, but a bit more stand-alone than https://github.com/hoglet67/PiTubeDirect/releases ?
But why??? Do you have a customer in mind?

Yep. I try to suggest ways to address the Cortex-M market (no real MMU there) with something closed to RISC OS. Linux is not so good here while RISC OS, DDE, etc. could be a good base.

The ARM 32bit market is not dead on Cortex-R and Cortex-M. It’s a market where bare metal offers are still common, and where the demand for ‘lite-OSes’ is strong. Here, there is a potential real market for RISC OS.

On 64bit, the war was won years ago by Linux and Android. IMHO macOS and Windows are both on niche markets today. And there are both much much much better than RISC OS on every aspect. Even if we can do the impossible, they have also much much much more workforce to stay ahead.

and then inject into that the assembler version code.

Alternatively, figure out what is supposed to happen and implement that in C, even if it doesn’t exactly follow the assembler. So long as the outputs are the same for the same inputs…

Why? Because with conditional execution and the use of B/BL, I’d imagine a straight conversion would lead to an enormous pile of linguine.

Because with conditional execution and the use of B/BL, I’d imagine a straight conversion would lead to an enormous pile of linguine.

This, exactly. (The subject of discussions among engineers, in my hearing, at ARM 15 years ago…)

It’s a market where bare metal offers are still common

Yup. I would imagine it’s not unlike the ESP32 in use, in that code written in sort-of-C is compiled to object code and statically linked with a small operating system stub, then flashed to the device.

The question I would have is how much of RISC OS would actually be useful, especially given the smallish environment (the chip in my drone is an M0 device which appears to have 96K flash and 32K RAM, plus the usual selection of I/O.

Can’t help but think that we’re possibly looking at more of a BIOS than an OS.

and where the demand for ‘lite-OSes’ is strong.

Such as this?

As is usual, we’d be playing catch-up.
But, again, how much of RISC OS would be useful in this scenario? No MMU, no video output, or video/audio system period.

It’s a very different world to the ARM development boards and the Pi family that are already supported.

Translating RISC OS 5.28 (or such) from assembler to C is only relevant to 32-bit(/supporting) CPUs instruction sets and is 100% irrelevant to an ArmV9 64-bit version of RISC OS. The discussion brewing here deserves its own thread if it’s more important than 64-bit RISC OS which could save the platform from extinction in the semi/professional desktop workstation/laptop markets. Tabula rasa.

You know, I was wondering on the way home how long would it take the average garden snail to slime it’s way across a standard Pi case.

For an attempt at an answer…they move at about eight centimetres a minute when pedal to the metal, so if we assume climbing up one side, across the top, and down the other side, it ought to take “about two to three minutes”, depending upon the snail.

There.

Now you know.

I keep coming back to this discussion, feeling guilty, and switch back to trying to work on a C Kernel using gcc. I’ve just narrowed down a cute little bug, that can be summed up like this:

|extern int rma_heap;
|#define OS_Heap 0×1d
|
|static inline void *alloc( int size )
|{
| register int code asm( “r0” ) = 2;
| register void *heap asm( “r1” ) = &rma_heap;
| register int bytes asm( “r3” ) = size;
| register void *memory asm( “r2” );
|
| asm ( “svc %[swi]” : “=r” (memory) : [swi] “i” (OS_Heap | 0×20000), “r” (code), “r” (heap), “r” (bytes) : “lr” );
|
| return memory;
|}
|
|void test()
|{
| {
| int *p = alloc( 12 );
| *p = 55;
| }
|
| {
| int *p = alloc( 12 );
| *p = 77;
| }
|}

Which compiles (with maximum “optimization”) to:

test:
push {lr} ; (str lr, [sp, #-4]!)
mov r3, #12
mov r0, #2
ldr r1, [pc, #16] ; 24 <test+0x24>
svc 0×0002001d
mov r3, #77 ; 0×4d
pop {lr} ; (ldr lr, [sp], #4)
str r3, [r2]
bx lr
.dcd 0

Can anybody spot the problem (joking, it’s decided that the assembler must produce the same result with the same parameters)? Or even better, tell me the solution?

Now I have to get a later version of gcc to see if it’s been fixed and raise a bug report if not. I’ve probably left out something like one of !"£$%& in the assembler and be told (once more) that I’m just too dumb to understand the inline assembler. The worst part is that it’s in code that’s been working for months, or so I thought.

The question I would have is how much of RISC OS would actually be useful, especially given the smallish environment.

A good question. Probably not much, but perhaps enough to get some sort of software compatibility between CLI tools and the tools deployed on the chip. And if the subset of the OS is really a subset (not something totally new) that could be a way to solve the two main problems I did encounter in the MCU world: no way to launch the code in a native way on the dev platform (yes, we have emulation, but this approach has its limits) and a solid stack with the same bugs as the SDK stack (a lot of bugs are OS, libs or compiler bugs, that’s why people at Ashiv almost always remove all possible layers for their embedded work and just use ASM + some basic SWI).

Translating RISC OS 5.28 (or such) from assembler to C is only relevant to 32-bit(/supporting) CPUs instruction sets and is 100% irrelevant to an ArmV9 64-bit version of RISC OS.

OK, so you speak of a completely new OS, based on the ideas of RISC OS, but not a C version of RISC OS. Something as different as RISC OS than RISC OS was different from BBC MOS.

Why not. But please don’t call it RISC OS.

Chris:

ldr r0, [r1, r2, lsl #2]!

Means: Load the word 4 * r2 bytes above r1 into r0, and update r1 with the calculated address i.e. r1 = r1 + (r2 << 2), r0 = word at r1.

Without the !, it doesn’t update r1, but still uses the calculated address.

Can anybody spot the problem

Nice.

Isn’t it just? There’s a few weeks down the toilet. Versions 8, 9, and 10 all do the same.

Isn’t it just? There’s a few weeks down the toilet. Versions 8, 9, and 10 all do the same.

This is the nice mature compiler that will save the day!

And I am too stupid to understand the inline assembler. Put “memory” in next to “lr”, and we’re golden. On to the next bug….

Just for the record, the symptom was a looped linked list, because the “new” item was the same as the previous, so it linked back to itself.

Oh “memory” (the special clobber value) as opposed to the ‘memory’ return register value! Brill.

Yeah. It does make sense, though, telling the optimizer that the assembler has side-effects. Now I wonder how many other inline assembler fragments need that, too.

telling the optimizer that the assembler has side-effects

Um, so what’s wrong with borrowing the “volatile” keyword that every competent programmer knows the meaning of?

That’s got some other mystical meaning. asm volatile (…) ensures the code gets put there and not somewhere else. Honestly, I’m still not sure when it’s needed.

I’m writing up a list of my problems with it.

ensures the code gets put there and not somewhere else.

inline ‽

I’m not in a position to affect the GCC Juggernaut.

https://github.com/Simon-Willcocks/RISC-OS-Kernel-in-C/wiki/GCC