At 03:52 PM 9/23/2001 -0400, Mathieu Bouchard wrote:
>On Fri, 21 Sep 2001, Pedroni Samuele wrote:
> > I don't know if you are aware of that, but the Parrot VM
> > both has instructions that deal with static typed data
> > integers (IV?) , floats (NV?) and strings (STRING)
> > so you can't delay the problem of a string library
> > to the dynamic typed stuff (PMCs) like in Python
> > But clearly the PMCs and how to implement
> > python runtime and semantics through them
> > and how easy is "our" problem.
> > A "Parrot Python String" will not be a STRING
> > but given there are STRINGs it should be
> > decided how they work...
>
>Some thought I had on this topic...:
>
>Compiling Python and Ruby source-code to Parrot byte-code won't ever
>generate any integer-specific, string-specific, or float-specific opcodes,
>except to the extent required by the implementation of Python's and Ruby's
>object systems in Parrot. (and also except if someone writes a really good
>optimiser.)
Your parenthetical statement is important, and it's one of the places that
the int/float/string registers will get used, along with them for temporary
values and low-level code. (Where you're writing code to implement various
stuff and don't feel like kicking down to C)
While the compiler writers will have some serious incentive to use the
int/float/string ops and registers, they're really not the primary focus of
the interpreter. It just looks like that right now since they're the
easiest things to get going. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
