embeded parrot with start / stop

Peter Lobsinger plobsing at gmail.com
Thu Nov 25 04:46:32 UTC 2010

On Tue, Nov 23, 2010 at 9:27 PM, Jonathan Leto <jaleto at gmail.com> wrote:
> Howdy,
>>  * parrot in its current form is hardly "small". tweaks are available
>> to pair it down significantly, but they aren't the default, so it
>> would be some work to find and use these optimally.
> Define "small".

I'd say the low-end of the range of systems on which one might
consider it reasonable to run something similar to parrot would have
limiting memory resource (ram/rom/flash) of single digit to low double
digit Mb. Possibly without an MMU (eg: uclinux), making large
allocations problematic due to the potential for fragmentation.

My libparrot.a is 21M, libparrot.so - 9.9M.

To do anything useful, you need a pbc, which aren't optimized for
size. lua uses a main pbc of 908K. winxed - 856K. nqp - 1.4M. Not to
mention, these are *copied* to memory (as opposed to mmaped), making
their size even more of a problem.

All told, that's very big for someone on a tight memory budget.

>>  * parrot has no considerations for external halting and restarting
>> like you've described (maybe we should, but we don't ATM). you would
>> have to write an alternative runloop (not that hard, honest), or you
>> might be able to tie-in with the gsoc instrumentation framework (not
>> all there quite yet, but close)
> Why is an alternative runloop necessary? What assumptions require a runloop?

The key here is halting after N instructions given arbitrary bytecode.
I know of no way of doing this in parrot currently, and suspect that
it is not possible or at least difficult.

Since it is the runloop that actual executes each of the instructions
in sequence, it seems most natural to keep track of how many have been
run there.

> Why can't serialization be used?

There are many answers to this:
 * continuation.pmc doesn't implement the freeze/thaw interface
 * full runtime serialization is roadmaped for parrot 3.6
 * we have hardly even begun to think about how this could/should work

> Duke
> --
> Jonathan "Duke" Leto
> jonathan at leto.net
> http://leto.net

More information about the parrot-dev mailing list