Parrot Platform API

[Vishal Soni]

Hi Chip,

I have been looking at the Parrot code for last couple of weeks. While going
through the code there were a few things that striked me. There are quite a
few places where #ifdef constructs were used to define platform specific
code (#ifdef WIN32).

I was thinking would it make sense to define a Parrot Platform API that all
parrot ports need to implement. This is very similar to the Linux kernel
source. During the build time we should be able to resolve the platform
specific code and link it in the parrot executable. There are couple of
advantages of this.

1. Define a clean API that new parrot ports need to implement.
2. Keeps platforms specific code out of the parrot's core logic.
3. The new ports will not introduce bugs for already working ports.

I have had some discusion with Leo about this and he thought it might be a
good idea to run it by you.

My initial thoughts are we could include following things could be added
to the Parrot Platform API:

1. File I/O. This includes sync as well as async I/O. For platforms that do
not have native Async I/O support we could build an emulation of Async I/O.
2. Network I/O: This would include API for TCP, UDP and possibly SCTP
(Stream control Transmission protocol).
3. Threads and Mutexes
4. Signals / Events ()
5. Environment: API to read the environment variables from OS
6. Math library (we could possibly use http://www.netlib.org/fdlibm/ for
platforms that support IEEE 754 floating-point arithmetic)

The idea is to define a clean seperation between parrot and the platform
parrot is running on. The Parrot Platform API would possibly be the
interface via which the Parrot VM discovers the platform specific
functionality.

A good example of a simiar abstraction is the Apache Portable Runtime (
http://apr.apache.org/). This is used in the Apache HTTP Webserver.

Let me know what your thoughts are. I would not mind writing up a draft PDD
or doing some proof of concept work.

--
Thanks,
Vishal

[Nicholas Clark]

On Mon, Jun 26, 2006 at 12:08:52PM -0500, Vishal Soni wrote:
> Hi Chip,

> Let me know what your thoughts are. I would not mind writing up a draft PDD
> or doing some proof of concept work.

Chip's currently at YAPC::NA, and he's not yet presented his talk, so I'm
guessing it might be a little while before he gets a chance to read any of
his e-mail.

Nicholas Clark

[ncan...@gmail.com]

> Hi Chip,
>
> I have been looking at the Parrot code for last couple of weeks. While going
> through the code there were a few things that striked me. There are quite a
> few places where #ifdef constructs were used to define platform specific
> code (#ifdef WIN32).
>
> I was thinking would it make sense to define a Parrot Platform API that all
> parrot ports need to implement. This is very similar to the Linux kernel
> source. During the build time we should be able to resolve the platform
> specific code and link it in the parrot executable. There are couple of
> advantages of this.

Yes I support this way of doing, this is the way NekoVM
(http://nekovm.org) has been designed. The VM is entirely separate from
the standard library, and there is a clear difference between
"builtins" (VM low level functions that might be optimized into
opcodes) and "primitives" (C libraries functions).

Nicolas