[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