[pypy-dev] Proposal of timeline
Antonio Cuni
anto.cuni at gmail.com
Mon Jul 23 13:07:55 CEST 2007
Hi Paul,
I'm cc-ing pypy-dev.
Really, don't be shy and don't worry to bother the list with your
questions. They are not spam. I'm sure that the others are happy to hear
your questions and also to answer in case I can't do it immediately (as
happened in the last weekend).
Paul deGrandis wrote:
> Antonio,
>
> I've been working on the JVM backend. When I trace the float tests that
> look at uint handling, weird NEGATIVE values pop up. I originally
> associated these with overflow, but it's a different issue. Any
> insight? The way to do unsigned values in Java is to use the next
> primary type larger, for example, a uint is stored in a double... but
> currently no checks exist for negative values.
as Niko pointed out unsigned types are stored in the corresponding
signed types in the JVM: this is ok becasue they occupy the same amount
of bits, but you have to been careful when dealing with them because the
JVM thinks you want to represent a signed value. In particular, if you
try to print one to stdout it will be printed as a signed, and so this
might be the reason why you see negative values. You have to write a
custom procedure to format unsigned values into the right human readable
implementation. Please note that this is necessary only during testing
or when doing I/O: as long as your unsigned values are kept inside the
JVM, they works just fine (apart from comparisons).
The simplest way I can think to format an unsigned into an human
readable form is to convert it into a double, as I already wrote in a
previous email:
double from_uint(int x)
{
double res = x;
if (x < 0) // i.e., the leftmost but is 1
res += 4294967294;
return res;
}
But again, you should use this *only* for I/O and testing, not for doing
any real operation.
> I looked at the test_overflow but these tests don't make sense for the
> jvm. You have overflow built in to CLI so you want to make sure that
> ovf_check from the rpython definition works, but the JVM defines these
> operations. What exactly are these tests aiming to illustrate and test?
RPython is a language with a (more or less :-)) well defined semantics,
so every backend must take care of implementing this semantics
correctly, even if it's not natively supported by the underlying platform.
In this particular case, RPython programs expect overflow to be detected
correctly. If the JVM does not do this for you, you have to handle those
cases by yourself. GenC has the same problem: the C platform does not
detect any overflow, so it must explicitly check for that; you can
easily reuse the same logic; for example, this macro is taken from
translator/c/src/int.h:
#define OP_INT_ADD_OVF(x,y,r) \
OP_INT_ADD(x,y,r); \
if ((r^(x)) >= 0 || (r^(y)) >= 0); \
else FAIL_OVF("integer addition")
for genjvm, you could e.g. write a java function doing the same (and
raising the appropriate exception in case of overflow).
> I haven't tackled overriding default values (as skipped in test_class)
> yet, but that's really all there is needed left to pass the test_class
> requirements
I think you could skip this for now. IIRC it's only needed to translate
pypy with the thunk objspace, it's not a priority.
> I'm still working on the others, but I don't think I'll have trouble
> having these first bugs fixed by the end of the work day on the 27th.
ok, that's cool! :-)
> Lastly, what is the easy approach to I/O and external functions?
the easy approach is to forward the external functions to the backend,
which will take care of rendering them as appropriate (usually by
calling an helper function written in java). This approach is already
used to implement time.time, time.clock and os.write: you can find their
implementation in jvm/src/pypy/PyPy.java (ll_time_time, ll_time_clock,
ll_os_write). The code that calls these functions is in
jvm/generator.py, method 'call_primitive'.
ciao Anto
More information about the Pypy-dev
mailing list