System architecture

[Jon Taylor]

Hi again,

In this post I will lay out the basic architecture of the system, in
much greater detail than was first given in the overview document.

The native code is written in C or assembly and is executed first,
after the bootloader finishes loading and uncompressing an initial
image into RAM. This image must contain the native code and perl
system image, and can also contain data sections such as an initrd
image, special native code or data sections or other such "custom"
data. The format of the initial image should be a simple hierarchical
filesystem tree - probably a compressed tarfile will do. If .tar.gz
extraction support needs to be added to GRUB or another bootloader, it
should be - the current support for booting a compressed kernel+initrd
image is somewhat unsophisticated and does not allow for generic data
to be specced out of a generic image and into RAM without booting any
specific OS code. Also added to GRUB if needed should be a simple
linear page allocator, so that the files in the filesystem image as
well as an associated index can be dumped into un-pagemapped physical
RAM and accessed through offsets and size values.

Once the initial image is uncompressed into RAM and accessible, the
native mainloop runs, picks up its inital parameter string from the
bootloader and begins to execute setup code. The first setup task is
to initialize the CPU, not assuming anything about what the bootloader
has already done. Next, the system RAM has to be mapped into several
segments: initial bootloader image data, stack region, Perl heap, a
generalized types shared data region and pagetable structure. Once
that is done, the Perl executor can be run and passed an initial
argv[] string, kicking off the Perl-side mainloop.

The Perl mainloop serves mostly to manage the scheduler class init, as
well as to catch and handle scheduler termination. The initial
parameter string specifies a set of perl code modules to enqueue into
the scheduler FIFO before the scheduler is started, as well as
associated parameter strings for those modules. Minimal startup
involves two top-level processes off the initial scheduler, a
interrupt bottom-half process scheduler running at maximum privilege
and a standard user process scheduler running at secondary privilege.
The user scheduler minimally starts with a Perl interpeter shell
running as the sole process. Assuming that the scheduler and
underlying Perl interpreter work properly, this should provide an
intial interactive systems environment.

A scheduler crash or termination of the last system processes will
drop the flow of execution back to the Perl mainloop, at which point
the mainloop code with either decide to continue around and
reinitialize and restart the scheduler, or it will terminate with an
error and exit the perl interpreter back to the native mainloop.
Likewise, the native mainloop will decide either to contine around and
reinitalize and restart, or it will have to fail and die, rebooting or
hanging up the hardware.

Other native code sections: The system top-half handler will need to
be natively specified, pushing its reported IRQ condition to the
system shared memory region for later pickup by the Perl-side bottom
half code. The virtual memory exception/fault handler code will also
be native, pushing conditions onto the shared memory region for pickup
by the VM bottom half Perlside code. The last major native section is
native executor, which will integrate with the Perl heap and interface
a generic Perl calling convention with a specific native ABI and
execute the native binary section as a critical process once a timer
interrupt has pulled native execution away from the Perl executor
running the scheduler and process heap.

Device driver code will be simple PerlIO layers, reinterpreting binary
data sent into and out of the layered sections using the standard file
IO functions. Nothing is needed at the native level to support this
other than VM exeception handling and the Perl Pointer classes from
CPAN for native bus access. DMA completion conditions will be posted
as Perl events generated by the appropriate bottom half IRQ handler.

Jon