[pypy-dev] Re: Base Object library (was: stdobjspace status)

Paolo Invernizzi paoloinvernizzi at dmsware.com
Thu Feb 27 13:00:12 CET 2003


> -----Original Message-----
> From: Armin Rigo

> *All* types are expected to be computed during type inference.
> So don't even say that W_ListObject.objarray is a list of wrapped
> objects or Nones -- this can be figured out automatically.

<snip>

> Consider for example the case of *two* different implementations
> (that would both appear as having the 'int' type to users).
> Say that one is like Christian's W_IntObject+r_int, and the other
> one can only encode small, tagged integers.
> The choice to use one or both representations in an actual C
> implementation must be made by the RPython-to-C translator, and
> not in the object space.

<snip>

> The original intent of classes like W_IntObject was "one class, one
> implementation", and I think that we must stick to that idea because these
> classes are what are used for the multiple dispatch routines.

Can you point out some idea about the *work* of the RPython-to-C translator?

I can only imagine what I pointed out in the last email...

<FOGGY>

- The RPython-to-C translator check the source code of the application for
*static* *compile-time*
  optimization.

- The RPython-to-C translator run the application under some objectspace.
  If I've understood well the idea, the application is the pypy-interpreter
PLUS the application...

- It performs introspection and optimize changing on-the-fly things.
  Some W_XXXObject is replaced with other, probably more *restricted or
suited to the
  target the specific code emission*, ex the W_IntObject+r_int.
Donno if this phase is to be done, I guess is an *additional* layer but
remembering the discussion about the stack dept calculation, this can be the
way to tell if all in the application is ok and aid the compiler...

- loop analysis on even-more-restricted source

- Finally emit C code for that specialized-parts, for example code that
mimics current CPython functions for pypy-part of the interpreter, or code
that recall the specialization done by psyco.

</FOGGY>

Paolo Invernizzi




More information about the Pypy-dev mailing list