Perl interpreter changes

6 views
Skip to first unread message

Jon Taylor

unread,
Aug 5, 2011, 5:07:21 PM8/5/11
to perlos
Hi again,

Now it is time to discuss what type of changes to the standard Perl
code interpreter need to be made to allow it to run native on top of
bare hardware. The existing codebase is rather small, so it can be
assumed that this is not a difficult task. A fork of the standard
package will be maintained util such time as it is feasible and/or
desireable to merge the PerlOS changes back into the standard
package. Until that point, new revisions of the Perl interpreter
source will need to be diffed and merged into the PerlOS sources on a
release by release basis.

One of the changes PerlOS will make will be to remove most if not all
of the malloc()-using dynamic memory accesses within the Perl
interpreter. What cannot be converted to use static compile-time
allocations will need to be rewritten to use a primitive page
allocator of some type, bypassing the PTE which is reserved for in-
Perl use only.

The next major change involves low-level system access methods. All
system I/O requests will either use Pointer:: directly or (hopefully)
the PerlIO:: classes and methods (which will presumably themselves end
up using Pointer::). Nothing other than Pointer:: should be used to
connect to the native layer.

The Perl interfaces for wrapping system abstractions in iperlsys.h
will also be removed. The Perl code sections which make use of these
primitives (sockets, processes, getenv() and friends, POSIX fileio,
and a few others) now will need to be rewritten to use PerlIO:: to
communicate with low-level library or device driver code layers, which
will need to be written as well.

Finally, there is some dependency on string.h and stdio.h in the Perl
interpreter sources. Since we will not be either statically or
dynamically linking to the C standard library, These need to be picked
up and integrated, probably from some libc sources which are license-
compatible with Perl.

I think that's it. The bulk of the work will involve A) writing the
Perl-based device driver code, and B) rewriting the iperlsys.h-using
perl code to make use of the device driver stack. A primitive console
driver layer wrapped around a keyboard, mouse and textmode/video
driver layer set should get an interactive system up and running for
testing and demonstration purposes, after which the rest of the
iperlsys.h interfaces can be moved off into their own PerlIO layers
and stacks.

Jon

Jon
Reply all
Reply to author
Forward
0 new messages