HelenOS as a foundation for next generation RISC OS

The point is that the current SWI-based API is NOT APCS-32, so changing to that would break everything.

Don’t delude yourself. Nobody is going to write new assembler modules ever again. I haven’t done a pure assembler module since 1988.

No one is going to win this debate, simply because it’s a matter of taste. Some like coffee. Some like tea. And ultimately you can’t tell people what they want.

A split could happen, but this doesn’t necessarily have to be a bad thing, and it doesn’t have to be an end to cooperation.

And take a look around, at all of the work by all of the people using RISC OS. You will be surprised by the amount of new assembly language written components of software, including modules. That is something still true of RISC OS that people still write advanced projects for this OS in assembly, or at least in part in Assembly.

The last “advanced projects” in pure assembler were probably Artworks and Sibelius. Artworks is now a mixture of Assembler and C, the other is dead on RISC OS and got rewritten in a HLL on Windows.

So I am interested which “advanced projects” you are talking about. Maybe it is just our definition of “advanced” that is different.

No one is using assembler to write OS or application code any more, it is jtust not a sensible use of time to write non portable code. I’m not just talking about portability from 32 to 64 bit, but old 26 bit code, alignment issues and the SWP instruction, all of which break in assembler, but if writen in C can just need to be recompiled with a recent Norcroft/GCC to fix.

One of the reasons for using assembler was for optimal performance, but that isn’t a given any more. There are now RISC OS machines using a range of different cores with far larger ISAs, and producing code which is optimal on all of them by hand is impossible. A compiler can produce either a general build which is ok for all, or code optimised for a specific CPU.

The only use of assembler now is by people writing the initialization code to bootstrap a chip, and those writing compilers. i.e. its a specialism not a general purpose solution.

The last thing we need on RISC OS is more assembler being written to become rapidly obsoleted, and abandoned.

One of the reasons for using assembler was for optimal performance, but that isn’t a given any more. There are now RISC OS machines using a range of different cores with far larger ISAs, and producing code which is optimal on all of them by hand is impossible. A compiler can produce either a general build which is ok for all, or code optimised for a specific CPU.

Indeed. Those who write compliers typically know a lot more about optimising machine code than those who write applications. And as CPUs become ever more complex (with machine code drifting ever further towards being a high level interface for what is truly going on the core) this will become more and more true.

Now the AARCH32 ISA is pretty well set in stone, to never again change.

Indeed, in much the same way that 6502 Assembler is pretty much set in stone, or Classical Latin. If RISCOS is tied to AARCH32 ISA, it’s on its last legs. That might be so. It’ll probably last me out – just about.

I pretty certainly won’t last fifty more years, anyway. I’d be breaking world records if I did.

I didn’t know 68K HW is still being produced; that fact doesn’t mean that every architecture will live that long – most don’t.

I’d be very surprised if AARCH32 is still being manufactured ten years hence, never mind fifty. Old stock? Maybe another five after that. My own machine? Rest of my life, even if I live to a good age – if I’m lucky.

RISCOS might last longer, running on something else, but I’m not very optimistic about that.

David

Look around. You say “NO ONE” does, then where do these newer written in assembly code come from.

So Assembly is no longer something that can be argued against for RISC OS.

Some people do enjoy writing in assembler and it’s certainly more fun on the ARM and in RISC OS than, for example, x86.

If you want to write new RISC OS modules and programs in assembler, go for it.

If you want to change the minds of the regulars here who are choosing C, I’m afraid you’re wasting your time.

No interest in changing anyones mind. If you like any given language use it.

Fair enough.

I used to write in Assembler because BASIC wasn’t fast enough for what I wanted to do, and I find assembler (particularly ARM assembler, but I’ve used several others down the years) easy, whereas I’ve never really got my head around C. But BASIC is fast enough for everything I want nowadays, and I’m not writing modules (although there are a couple of existing ones I’d actually like to edit – but probably never will).

RISCOS might last longer, running on something else, but I’m not very optimistic about that.

And there will probably be no none using it anyway :)

@ DavidS

I am still waiting to see what the native side of assembly for ARM HelenOS looks like. As I can not find the version to run on ARM RPi I am currious.

If you mean the ARM ASM used in the HelenOS kernel then it’s minimal (as it should be to have a portable kernel) and you can find it here:

AArch32: https://github.com/HelenOS/helenos/tree/master/kernel/arch/arm32/src

AArch64: https://github.com/HelenOS/helenos/tree/master/kernel/arch/arm64/src

HelenOS could possibly be used also on older machines:

static const char *architecture_string(cpu_arch_t *arch)
{
	static const char *arch_data[] = {
		"ARM",       /* 0x0 */
		"ARMv4",       /* 0x1 */
		"ARMv4T",      /* 0x2 */
		"ARMv5",       /* 0x3 */
		"ARMv5T",      /* 0x4 */
		"ARMv5TE",     /* 0x5 */
		"ARMv5TEJ",    /* 0x6 */
		"ARMv6"        /* 0x7 */
	};
	if (arch->arch_num < (sizeof(arch_data) / sizeof(arch_data[0])))
		return arch_data[arch->arch_num];
	else
		return arch_data[0];
}

If you meant the specific bits for the RPi they are here: https://github.com/HelenOS/helenos/tree/master/kernel/arch/arm32/src/mach/raspberrypi

If instead you mean to use ASM to create an Application on HelenOS then the ASM syntax is the usual GCC GASM Syntax for ARM (either ARM32 or ARM64).

And finally if you meant the API access then HelenOS has a preemptive scheduler which makes application coding easier than on RISC OS:
https://github.com/HelenOS/helenos/blob/master/kernel/generic/src/proc/scheduler.c

So you probably need less code than in your example above if you code straight for HelenOS. Also HelenOS comes with its own “WIMP” which has (obviously) its own API. To access it from ASM source in user space you can use the standard “low level programming” techniques you would use in regular GCC on Linux for example or BSD and obviously call a different API. So on This HelenOS works as a modern OS (aka SWI/SVC are used only to call the Kernel, not everything).

Does this answers your question?¹

fn.1 With that said I am not pushing for HelenOS, just answering a question, that’s all.

Yes it is the native API of the native WIMP and other systems that interests me

Here then few examples for you:

https://github.com/HelenOS/helenos/blob/master/uspace/app/hello/hello.c

https://github.com/HelenOS/helenos/blob/master/uspace/app/calculator/calculator.c

More in general UI API here:
https://github.com/HelenOS/helenos/tree/master/uspace/lib/ui/include/ui

Full UI implementation here:
https://github.com/HelenOS/helenos/tree/master/uspace/lib/ui

Also HelenOS already implements a minix and a Posix API, so it’s not much different that coding on BSD for example.

@ DavidS

I am hoping that the calling convention is not quite as bad as that of that used by run time linked libs in Linux and alike,

One day you like Amiga OS / Atari TOS and then another day you say things like above, make up you mind my friend :D

The API in HelenOS is the C USUAL API David, so similar to all the UI APIs in the world (where also AmigaOS Intuition and Atari TOS GEM/AES has similarities), aka is not the SWI API that is peculiar to RISC OS only.

The difference in HelenOS is that HelenOS is a micro kernel and uses messaging for a lot of things, which IMHO is quite nice actually, however not sure how performant it is compared to more monolithic kernels

Paolo wrote:

The difference in HelenOS is that HelenOS is a micro kernel and uses messaging for a lot of things, which IMHO is quite nice actually, however not sure how performant it is compared to more monolithic kernels

The answer is in the FAQ. The question is, “Are microkernel-based systems inherently slow?”

No, but there is an inherent performance penalty stemming from the higher number of context and address-space switches of the microkernel-based systems as compared to the monolithic operating systems. ​Literature however tells us that this penalty can be as low as around 6%, if the system is implemented with due care. The penalty should be viewed as a price of the benefits we get with these systems. It’s analogous to sacrificing a little bit of performance for the comforts of using high-level programming languages.

If we end up using it, then a bit of a head start. If we go with something completely unreleated then, well I learned something allong the way.

I don’t think anyone is working on this, because to work on this it requires first to “un-spaghetti” RISC OS Kernel (I mentioned this in few topics already, so no need to repeat it again).

Otherwise the only other options are:

• Create a special HAL for RISC OS to talk with HelenOS and run it in an emulator of some sort because the two cannot run on the same CPU.
• Or run HelenOS on a set of cores and RISC OS in another, again modify RISC OS HAL to intercommunicate with HelenOS, but in both these two cases RISC OS would run in a separate space than HelenOS and so I’m not sure what advantages there would be for RISC OS.

Charlotte mentioned to use an approach like the Gerph Pyromaniac which makes sense if someone wants to rewrite the entire RISC OS API on top of HelenOS, but let’s not forget that pyromaniac is not yet a full “RISC OS WINE” and even WINE that is pretty much such type of approach (without the emulation of Unicorn of course) and has been in development for many years and has a similar API approach to all modern OS (so nothing as peculiar as RISC OS) still has problems, so no idea when such an effort may be fully working tbh.

I am guessing that I am missing something. While yes it will take a good amount of work it looks like you are trying to make it even more complicated than it would be. It is complicated enough of a process without trying to artificially add complexity.

What “artificially add complexity” are you talking about? I am not adding anything nor I have any intention to work on this effort. You asked questions on HelenOS clearly because you do not know how it works yet and then you say things like you already know what to do… weird. Anyway remember the Devil is into the details.

The stuff I said would be true no matter the host system used for the effort, as I do know the RISC OS side of it.

It just sounds like you are wanting to do a bunch of extra to RISC OS before anyone even trys to start on any host OS. It sounds as if you wish to assume that a huge amount of effort needs done before there is any evidence of it.

Almost like you wish to make sure it forever is stuck on ARM32 by requiring more work before it is needed.

I can easily be reading you as saying more than you intend, as in this kind of communication it is sometimes hard to be accurate in ones meanings.

Never been against an R&D tbh. As I always state, please feel free to try, R&D is always good and if it brings you nowhere in terms of a “product” it definitely always brings you somewhere in therms of knowledge :)

Anyway good luck with your new endeavour!

As a relevant aside, how “sensitive” are executables compiled for RISCOS to factors outside the CPU core? Would an ARM 32 emulator with a hypervisor that recognised OS calls, fiddled with the communication registers appropriately and then resumed execution basically do the job, or it a lot more complicated than that? Is memory access just a case of ensuring that pointers returned by the hypervisor to the executable have something meaningful to point to, or do other things need taking into account?

@ Charlotte

As a relevant aside, how “sensitive” are executables compiled for RISCOS to factors outside the CPU core?

You should define what exactly you mean by “executables” AIF? ELF? Modules? Most modules try to run in EL2 (at least they need to enter EL2 via SWI call) and they assume they are linked to SCL for example (if they are written in C).

No RISC OS code right now addresses other CPU cores, unless it’s being expressly written for or it’s using something like Jeffrey’s SMP library.

So all RISC OS code right now assumes it’s being executed on a single core and single task OS (yes even the WIMP tasks which give back control to the OS/WIMP expressly).

If you’re talking about an AIF requirements, the SWIs and the calling conventions are expected to behave in a certain way, they could be replaced under the hood, but you need to identify exactly which one you want to replace: RISC OS native? 3rd parties Modules?

Would an ARM 32 emulator with a hypervisor that recognised OS calls, fiddled with the communication registers appropriately and then resumed execution basically do the job, or it a lot more complicated than that?

Sure an ARM 32 emulator can be used to run the entire RISC OS on a single core as it happens now and in this case there won’t be any advantage to do all the work and run RISC OS on an emulator with the WIMP still managing the multi-application environment.

I think I explained this enough, to make the whole circus work as many seems to expect the first thing to do is to convert RISC OS from Assembly to C, this in order to simplify the required separation between kernel layers¹ which right now is a bit of a spaghetti architecture. The conversion to C will also help to remove “tasks management” out of the WIMP which is one of the most limiting factors for RISC OS right now (limiting it way too much).

To be close to your question, which exact RISC OS Kernel layer and functions should be affected (and replaced) by the Emulator? None? then you have an RPCEmu kinda situation. Some? which one (with the spaghetti architecture you risk the replacement to be called by something else in an unpredicted manner).

When the Kernel architecture is finally separated correctly then (and only then) one can pursue whatever path forward one would like, for example:

• Use HelenOS as a library of well implemented memory management and task management and use HelenOS process scheduler in RISC OS itself, basically this approach combines the micro-kernel with the RISC OS Kernel and simplify the work that has to be done to modernise RISC OS Kernel without the need to use Linux etc… (in this case RISC OS will stay fully RISC OS and will have a fantastic modern and as well fast architecture probably capable of competing with big systems and even beat them as well as introduce security and more, so top notch choice is you want my opinion). In this option RISC OS will still be monolithic (hybrid combination of HelenOS + reusable parts of original RISC OS kernel)

OR

• Use HelenOS as micro-kernel and run RISC OS on top of it. In this case you’ll be finally free to instantiate and entire RISC OS instance as a task of HelenOS and implement a messaging client for RISC OS. In this case WIMP no longer tries to run as a task scheduler so you’ll be finally free to run a program per each RISC OS instance and integrate the WIMP app or the CLI app with each-other by mapping the RISC OS messaging library in HelenOS.

Without the conversion to C and restructuring the RISC OS Kernel, every approaches will results to some sort of hacking the existing RISC OS kernel which always assume it’s a single task infrastructure and the WIMP trying to multi-task the applications on top of it which to me personally makes no sense because we already have RPCEmu running on Linux, Windows and macOS, so why even bother?

I am not trying to push ROOL’s point of view at all costs, but IMHO what ROOL is doing/asking is already the best path forward for every possible approaches, anyway up to you guys.

¹ and a correct definition of interfaces between each layer

(To belatedly reply)

So the upshot is that a full assembler to C conversion of the kernel is (for all practical purposes) a necessary preliminary to any form of microkernel RISC OS?

So the upshot is that a full assembler to C conversion of the kernel is (for all practical purposes) a necessary preliminary to any form of microkernel RISC OS?

IMHO, yes¹ it is a must “go through” in order to be able to pursue any other path forward, while, at the same time, maintain some sanity in all the possible divergences that may occur.

Obviously this is just my personal opinion.

¹ although if not a full ASM to C conversion. I mean in all kernels there is always a minimal ASM component for certain and very specific tasks.