Burl Nyswonger:
# I am concerned with the size of parrot recently --
# libparrot.so is like
# 650K, and libparrot.a is like 770K. This is stripped and
# without JIT (and
# there is a lot more to come, right?)
Actually, I'm not sure there's much left. More portable bytecode
formats, an extension interface, dynaloading, the compiler, and a
language interface may be it--and the dynaloading may help trim the core
size. (I'm sure I've left out some huge stuff. What did I miss?)
What -O did you use? See if your compiler has an "optimize for space"
option.
# The ability to build the VM in an extremely stripped-down
# configuration
# would be really useful for embedded environments (where you
# only have, say
# a 4MB flash that must hold a kernel, all libs, apps, etc...).
Hmm. Most apps on my Palm are like 10K, including all the GUI code and
stuff. Although they aren't as general.
I'd like to know a few things:
1. Rip out all the I/O stuff. Does that help? (I don't think it will
much.)
2. Rip out predereferencing. Does that help? (This could be big.)
3. Rip out the opcode lookup stuff (a function with a humungous switch()
statement, near the bottom of core_ops.c and core_ops_prederef.c). Does
that help? (I think this'll be big.)
# JIT can be
# turned off to make the VM smaller -- how about making it so
# that parrot
# can be optionally built without profililng, debug, etc. as
# well -- would
# that make it smaller?
I doubt it, but you could try. Most of that stuff is just a few lines
of code in the slow runops loop, although all of them have supporting
code scattered about.
EVERYONE: Should we have a PARROT_TINY_CORE define you can activate to
cut some of this stuff out?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
