Cake is a project mainly written in C and C++, based on the Unknown and 3 other licenses found.
The AROS cake. Goodness baked in, have it and eat it too. Delicious!
Here are some modifications of AROS structure.
This version of Aros build for ppc machines, requires gcc version 3.2 or newer. It requires also some patching in compiler as it uses "stackparm" function attribute proposed by Fabio and extended by me.
New target is added. Currently, in order to build Aros for PReP (PowerPC Reference Platform) machine, one can specify either --target=prep if the code is compiled on PPC based machine, or --target=prep-cross, if the code is compiled on other architecture (like x86 for example).
Added some target related definitions for objcopy, objdump and strip.
New directories are added. The "arch" is containing stuff which varies between different architectures. /arch/common contains code which may be shared between different architectures and platforms. /arch/ppc contains all ppc-reladed files. Similarly, /arch/ppc/prep contains PReP specific code, /arch/ppc/chrp contains CHRP (and probably also Pegasos!) related code, while /arch/ppc/common contains common code shared among this platforms.
/drivers directory is supposed to contain hardware-independant drivers shared among platforms. They cannot contain and direct IO/Bus activity. Everything HAS TO be passed through openpci.library and kernel.resource. Breaking this rule may produce driver which is totally unusable, so don't do that!
/kernel directory contains all the things that are needed to launch the kernel. Please note, that by term "kernel" I understand such piece of software, which is able to maintain multitasking, memory, messaging system and perhaps basic low-level activity. It means in Aros case the following modules:
Later modifications of this list are possible. Note, that all other modules may be loaded by bootstrap code (bootstrap talking with OpenFirmware in case of PPC machines).
Please note, that this version of exec.library doesn't allow any function replacing. It is also not functional. IT WILL NOT WORK without kernel.resource! Another important issue is, that this version of exec is suppost to have API which is 100% compatible with AmigaOS 3.1. Some additional functions are also provided. See docs for more details.
In order to allow future m68k emulation, special ABI is proposed for PPC machines. With exception of varargs functions, the new ABI doesn't require any changes in gcc.
The Include/aros/abi.h contains CallOS structure definition. It is used to pass parameters to all functions in libraries/devices/resources. It is also used to pass parameters to functions which are expecting them in given m68k virtual registers. Every task contains its own CallOS structure with r2 pointing to it. You may ever trust the contents of %r2 and you shoud never modify it!
In order to pass return value in m68k-like virtual register D0, there is also return(val) macro defined if compiling kernel-related code (KERNEL symbol defined)
the Include/asm/macros.h contains some usefull macros. Few of them make some effect on non-ppc architectures only. Important one is STACKPARM, which is used for functions expecting their parameters on the stack.
Because of lack of any stardart regarding parameter passing to kernel, I have written bootstrap code which talks directly with OpenFirmware, and delivers to kernel parameters in the same form as GRUB does. Because it's not too handy to fabricate them, we could provide our own standard. The startup is responsible for setting the machine correctly up, and fire the kernel. Exec's entry point is now
void STDCALL NORETURN LaunchKernel(ULONG, ULONG);
where the two parameters passed have the same meaning as by Multiboot standard. Allthough this is not yet fulfilled, the startup code has to exclude kernel from memory map delivered to LaunchKernel code. It's just easier to do on the architecture specific side than later from running exec.
The kernel contains two different configuration memory areas, which has to be writable. The configuration areas should be locked after the initialization. The memory map and bootloader informations are stored inside, together with information about loaded modules and memory areas which has to be scanned by RomTag scanner.
This area is (or has to be) the only writable part of kernel. It may be redirected to RAM on embedded systems (only the linking rule has to be changed).
Please note, that allthough kernel supports .bss section clearing, it's not welcomed in code. If AmigaOS kickstart was able to live without, we can also!
In order to port Aros to other architectures, one has to:
If only hardware drivers are here, it should work then.