C Kernel

Greetings, will we ever get to see RISC OS’ kernel rewritten in C? It could definetly improve the efficency of porting. Or, if it is planned. For what version estimated would it be released?

There are plenty of routines that could be written right now, for example a VDU driver.

My understanding is that the things that one can do in C in the kernel is fairly limited.

Perhaps the first job should be to teach the kernel about the C runtime, so that code written in C can make use of library facilities (stderr → DebugTX for instance), as well as stack checking and the like.

I mean, you’d definetly would be able to rewrite the stuff that is not necessarily only possible in ASM. The rest would be left to ASM, like drivers or very optimized stuff..?

I started rewriting it in C++ for x86 Linux many years ago, it managed to run FileSwitch, MessageTrans, ResourcesFS and BASIC.

I have partly reimplemented dynamic areas and OS_AMBControl in C with Linux system calls.

And someone else has partly reimplemented RISC OS in Python, with an online demo.

First we should:

1. Remove the SysCommsModule pseudo-module.
2. Build the kernel using relocatable AOF and support multiple source files.
3. Rearrange the directory structure.

In my honest opinion i think that a linux port would make RISC OS not so unique and fast, like it’d get lost in between other linux distros. RISC OS should stay as it is but be more of cross-platform than just ARM

Those changes all look good Timothy :-) Once somebody goes over the hurdle of putting the first bit of C in, it will give a template for other people to follow.

Can I please emphasise again to any prospective volunteers: you do not have to wait for the above changes before writing code. There are plenty of things to get stuck in with, which you can write as a standalone feature (as a module or even in an application test bed) and which we can join up with the system at a later date, whether that be putting into the kernel, or as a separate module.

I started rewriting it in C++ for x86 Linux many years ago, it managed to run FileSwitch, MessageTrans, ResourcesFS and BASIC.

Now that is a great effort! Very interesting with BASIC on x86.

For what it’s worth, pretty much the only thing you really need to run C code is a stack, and that’s just an area of memory. No standard C library or functions are required.

GCC has inline assembler for the very few times you absolutely need it.

A linker script can locate the appropriate code at the start of the object file (along with locations of important places, like the location of the page after the OS) and objcopy can create a binary image.

Here, for example, is some startup code for a Pi3 (in aarch64), your C code in c_el3_nommu gets a section of memory (with a stack at the top of it) for each core:

/* Copyright © 2020 Simon Willcocks */

// Establish a stack for each core, at the top of an anonymous struct Core, and call a C routine.
//
// The size of the Core structure must be defined at compilation as CORE_SIZE (I recommend a multiple of 4k)

typedef struct Core Core;

void attribute(( noreturn, noinline )) c_el3_nommu( Core *core, int number );

asm ( “.section .init”
“\n.global _start”
“\n.type _start, %function”
“\n_start:”
“\n\tmrs x0, mpidr_el1”
“\n\tmov x3, #”CORE_SIZE
“\n\ttst x0, #0×40000000”
“\n\tand x1, x0, #0xff”
“\n\tcsel x1, x1, xzr, eq” // core number
“\n\tadr x0, initial_first_free_page”
“\n\tmadd x0, x1, x3, x0”
“\n\tadd sp, x0, x3”
“\n\tb c_el3_nommu”
“\n.previous” );

Interesting – I didn’t know that you could place asm blocks outside of functions.

In terms of getting C code into the RISC OS kernel, I’ve taken Timothy’s relocatable AOF changes and built on top of them to allow ordinary C code to be used in the kernel. The data section has its address fixed at link time, so there’s no need to worry about relocation offsets, which makes things nice and simple when assembler needs to call into C or access variables in the RW/ZI data sections. Annoyingly I did have to write a custom tool to help with the linking; Norcroft’s binary output was appending the zero-init section on to the end of the binary, so instead I’m having it link to AIF and then my custom tool strips off the header leaving just the code/read-only section & the data used to populate the read-write section.

Expect to see those changes sometime in the next few weeks when the code to add OS_AbortTrap gets submitted.

Currently the code is being built with “-APCS 3/32bit/nofp/noswst”, the same as HAL C code, however that doesn’t match any of the build configurations that we’re using for libraries. So we might either have to switch to different settings, or update the shared makefiles so that suitable libraries can easily be built.

The .previous directive at the end is important, if you don’t want variables to end up in read-only memory.

My ld script is as follows, which allows memory management code to allocate memory appropriately.

/* Copyright © 2014-2017 Free Software Foundation, Inc.
Copying and distribution of this script, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. */
OUTPUT_FORMAT(“elf64-littleaarch64”)
OUTPUT_ARCH(aarch64)
ENTRY
SECTIONS
{
. = 0×0;
at_ro_start = .;
.init : { *(.init) }
.text : { *(.text) }
.rodata : { *(.rodata) }
. = ALIGN (4096);
at_rw_start = .;
.data : { *(.data) }
.bss : { *(.bss) }
. = ALIGN (4096);
at_rw_end = .;

}

Copyright © 2014-2017 Free Software Foundation, Inc.
Copying and distribution of this script, with or without modification…

Sailing close, turn away.

I think there are three whole lines of the original, and it doesn’t make up any part of the final product. Claiming copyright on that basis would be the same as claiming copyright because I edited the code using vim.

Sailing close, turn away.

??? Simon did exactly what that header expressly says to be allowed.

??? Simon did exactly what that header expressly says to be allowed.

Indeed he did.

Which takes us as close to GPL as we could deal with.

Your post is the first to mention GPL in this thread. Assuming that the code sample above contains the full copyright notice (as required by said notice) then the GPL isn’t involved. It appears to be an all-permissive licence.

It’s probably a lack of trust in anything to do with the FSF.

It’s probably a lack of trust in anything to do with the FSF.

Steve P randomly tossing off-topic © hand grenades into conversations; why? → Aldershot. Sighs.

Steve P randomly tossing off-topic © hand grenades into conversations; why?

Why indeed – massively entitled …

Sighs +=1

@ Jeffrey

or update the shared makefiles so that suitable libraries can easily be built.

If there is a chance to update the Shared Makefiles, can someone please have a look at the way CUtil is behaving? It systematically tries to link the util code against ansilib, not sure why, sounds more something left unseen from the dependencies on CApp or something…

I haven’t posted in bugs yet because I am not sure if this is a wanted behaviour or not, doesn’t make sense to me, but that doesn’t mean it’s a bug. The fix I use now it’s simple, just set `UTIL_LIBS =` after including CUtil, so not a big issue.

Thanks

can someone please have a look at the way CUtil is behaving? It systematically tries to link the util code against ansilib, not sure why, sounds more something left unseen from the dependencies on CApp or something…

Had a look in DDE30b using Steve Fryatt’s Locate.

AcornC/C++.Makefiles.CUtil contains :-

# You can't currently use the shared C library from a transient
UTIL_LIBS := $(filter-out ${CLIB},${APP_LIBS}) ${ANSILIB}

ANSILIB is defined in AppLibs and ModuleLibs :-

ANSILIB   = CLIB:o.ansilib

HTH.

yup David, thx.

As I said the fix in a MakeFile is super easy, just set UTIL_LIBS=(empty), so no need to alter my copy of SharedMakefiles. What I am asking mostly is: Is that ansilib linking a desired behaviour for reasons I do not know? hence the question here on the fly and not posting in bugs first.

For every future reading, I do not recommend to alter your DDE files, your changes may be overwritten during an update, so eventually set’s the variables as I shown in your own MakeFile instead.

What I am asking mostly is: Is that ansilib linking a desired behaviour for reasons I do not know?

I suspect it’s intentional. CApp & CModule both link to the shared C library by default, so for consistency it makes sense that CUtil would also link to a C runtime/library. And because the SCL doesn’t support utilities, they went with the next-best thing, which is ANSILib (a static build of the SCL).

However, when Julie Stamp ran into problems when trying to use CUtil with ANSILib, I could only find two examples of code in the source tree that use CUtil, neither of which use it “normally”, so it’s possible that it’s a bit broken/incomplete.

@ Jeffrey

I suspect it’s intentional.

I could only find two examples of code in the source tree that use CUtil, neither of which use it “normally”, so it’s possible that it’s a bit broken/incomplete.

Thanks a lot for the quick answer! Sorry for replying so late, but I am having a crazy day at work…

Ok will post something in bugs later then, cheers!

Perhaps one could contact Adrian L and see if they could use his CLib replacement library .If they want to write ‘C’ stand alone programs