C Kernel
Krzysztof Jeszke (6296) 30 posts |
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? |
Julie Stamp (8365) 467 posts |
There are plenty of routines that could be written right now, for example a VDU driver. |
Rick Murray (539) 13747 posts |
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. |
Krzysztof Jeszke (6296) 30 posts |
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..? |
Timothy Baldwin (184) 242 posts |
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: |
Krzysztof Jeszke (6296) 30 posts |
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 |
Julie Stamp (8365) 467 posts |
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. |
Michael Grunditz (8594) 245 posts |
Now that is a great effort! Very interesting with BASIC on x86. |
Simon Willcocks (1499) 505 posts |
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 (c) 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, #0x40000000" "\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" ); |
Jeffrey Lee (213) 6048 posts |
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. |
Simon Willcocks (1499) 505 posts |
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. } |
Steve Pampling (1551) 8125 posts |
Sailing close, turn away. |
Simon Willcocks (1499) 505 posts |
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. |
Steffen Huber (91) 1945 posts |
??? Simon did exactly what that header expressly says to be allowed. |
Steve Pampling (1551) 8125 posts |
Indeed he did. Which takes us as close to GPL as we could deal with. |
Chris Mahoney (1684) 2160 posts |
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. |
Rick Murray (539) 13747 posts |
It’s probably a lack of trust in anything to do with the FSF. |
Andrew McCarthy (3688) 601 posts |
Steve P randomly tossing off-topic © hand grenades into conversations; why? → Aldershot. Sighs. |
David Pitt (3386) 1248 posts |
Why indeed – massively entitled … Sighs +=1 |
Paolo Fabio Zaino (28) 1821 posts |
@ Jeffrey
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 |
David Pitt (3386) 1248 posts |
Had a look in DDE30b using Steve Fryatt’s Locate.
# You can't currently use the shared C library from a transient UTIL_LIBS := $(filter-out ${CLIB},${APP_LIBS}) ${ANSILIB} ANSILIB is defined in ANSILIB = CLIB:o.ansilib HTH. |
Paolo Fabio Zaino (28) 1821 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Paolo Fabio Zaino (28) 1821 posts |
@ Jeffrey
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! |
Colin Ferris (399) 1797 posts |
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 |