[pypy-dev] Re: pypy-dev Digest, Vol 9, Issue 3

[Scott David Daniels]

pypy-dev-request at codespeak.net wrote:
Armin Rigo <arigo at tunes.org> wrote (among other things):
> def my_function(a,b,c):
>   return a+b+c
> 
> the emitted machine code looks like what you would obtain by compiling this:
> 
> PyObject* my_function(PyObject* a, PyObject* b, PyObject* c)
> {
>   int r1, r2, r3;
>   if (a->ob_type != &PyInt_Type) goto uncommon_case;
>   if (b->ob_type != &PyInt_Type) goto uncommon_case;
>   if (c->ob_type != &PyInt_Type) goto uncommon_case;
>   r1 = ((PyIntObject*) a)->ob_ival;
>   r2 = ((PyIntObject*) b)->ob_ival;
>   r3 = ((PyIntObject*) c)->ob_ival;
>   return PyInt_FromLong(r1+r2+r3);
> }
Here we need to be careful about boundary conditions and wierd
cases.  On a 16 bit machine (for easy reading), 0x7fff + 0x7fff
should not go negative. While sign checks may work on two args,
they certainly won't work for three: 0x70ff - 0x7fff + 0x0005.

Also on Bengt Richter <bokr at oz.net>'s:
 > I'm also  picking this  place  to re-introduce  the  related
 > "checkpointing" idea, namely some  call into a builtin  that
 > can act  like  a yield  and  save  all the  state  that  the
 > compiler/psyco etc have worked up. Perhaps some kind of .pyk
 > for (python checkpoint)  file that could  resume from  where
 > the checkpoint call  was. I believe  it can be  done if  the
 > interpreter stack(s) is/are  able to be  encapsulated and  a
 > little restart info can be stored statically and the machine
 > stack can unwind totally out of main and the C runtime exit,
 > so that coming back into C  main everyting can be picked  up
 > again.

I did a checkpointing system for the SAIL language long ago and
far away.  The truly nasty part of a checkpoint is replicating
the environment outside of the address space.  Not only do you
have exception state, but you also have
  * file state: Does the file even exist anymore?  Do output files
    get re-opend in append mode, or re-created with copies of data?
    Is the input file really the same?  Do you _know_ that?  Do
    you simple seek and go?
  * system state: Which interrupts are armed, enabled, or
    suspended and pointed to what code in SAIL's case. I think
    Python's will be more about what callbacks are set and how
    to "passivate" things like Tkinter.
  * Hardware state I: Stop the program with a checkpoint after
    printing half a recipe.  Two days later run the checkpoint.
    The printer is not longer ready to finish printing.  This is
    not as nasty as: You have issued two bytes of a three-byte
    operation to an I/O device.  Post-Checkpoint the second time
    could be quite entertaining. This is why I decided checkpoint
    would cause a stop and run the checkpoint:  _slightly_ safer.
  * Hardware state II: Stop the program with a checkpoint after
    printing half a recipe.  Install a new printer.  Run the
    checkpoint.
  * Hardware state III: (Thank heaven for the old days). Stop
    the program with a checkpoint.  Replace the CPU.  Run the
    checkpoint.
  * Hardware state IV: Stop the program with a checkpoint.
    E-mail the checkpoint to a friend who runs it ont his
    zyglot-2000.

Checkpoints are absolutely wonderful.  You can build systems
that had several development phases, each represented by a
checkpoint.  In fact IMSSS at Stanford built some large systems
that way: We avoided elaborate macros to build data structures
by building theim in the first checkpoint phase.  We actually
had three levels of authors, two of whom were used to starting
at a particular checkpoint and building it to the next checkpoint.
The final checkpoint was delivered as our product.

In my experience, there is too much outside the language
system's control to provide the nice straghtforward thing you
(or really your users) want when they hear "checkpoint."
Programs often only check environmental things once, assuming
they can never change for the life of the process.  The OS type,
the display type, the current process id, ....  Be careful to
avoid someoner thinking of a checkpoint as a "secret sauce" that
they can smear over their program to allow it to magically
checkpoint itself every minute and hope to use any of the
checkpoints multiple times.

Chris probably has run into this with continuations, which can be
thought of as a kind of "internal code checkpoint."

-Scott David Daniels