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