On Mar 5, 2006, at 13:52, Joshua Isom wrote:
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't
work
yet), would suffice and is generated at compile time. Parsing .h
files
This way does the numeric values of the constants (at compile
time) get
frozen into bytecode written out to disk? Or does the generated
bytecode do
the lookup at run time on the run time platform?
Compile time. Using load_bytecode would be runtime, but a pbc of
one of those includes doesn't include any of the defines so those
would have to be rewritten to do something else, such as subroutines.
Yet another option: make a generic opcode (or internal Parrot routine
that opcode implementations can call) to retrieve the value of a
constant from a string constant name at runtime.
Though, I'm not sure making our whole I/O subsystem depend on integer
constants that vary from one OS to the next is a good idea anyway.
It's probably more sensible to have a standard representation
internal to Parrot (whether integers or strings or attributes of the
ParrotIO object), and compile a translation layer to retrieve the OS-
specific integer value where it's needed.
Allison
