Re: [pypy-dev] Low level operations and ootypesystem
Hi Antonio,
On Wed, Mar 29, 2006 at 11:12:03PM +0200, Antonio Cuni wrote:
The first doubt is about overflow-checked operations: I've noticed there
are a number of checked operations that can never fail due to their
semantic, such as int_lt_ovf or int_rshift_ovf: am I missing
something or are they simply redundant?
They are indeed redundant. We should check if anything can actually
generate them, and why. My guess is that nothing does, in which case
they can be removed from the table in rpython.lltypesystem.lloperation
as well as from the LLInterpreter (they have to be removed from both
places, otherwise test_lloperation complains).
We also need to kill one of float_mod or float_fmod. Right now they are
very C-ish: float_mod is like '%' in C, and float_fmod is like the C
stdlib fmod() function. The difference has to do with negative
arguments.
Moreover, I've found that the rtyper produces both int_lshift_ovf and
int_lshift_ovf_val: what's the difference between the two? And what's
the semantic of int_floordiv_ovf_zer and int_mod_ovf_zer?
The three-letter prefix tell which exceptions are supposed to be checked
for:
('ovf', OverflowError),
('zer', ZeroDivisionError),
('val', ValueError),
So int_lshift_ovf_val should check if the second argument is negative
and raise ValueError if it is, as in regular Python. Similarily,
int_floordiv is allowed to crash if the second argument is zero, but
int_floordiv_zer should check and raise ZeroDivisionError.
The second question regards uint_neg and uint_abs: considering the
an unsigned integer can't be negative, what are they intended to do? Are
they simply no-op?
Neither should be generated, as far as I remember, and they should be
taken out of the table too. This said, uint_abs is clearly a no-op
but uint_neg -- if used -- stands for negate the number and clamp it
back to the range of an unsigned word, which is the same as doing
~x + 1.
A bientot,
Armin
___
pypy-dev@codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] List and string in ootypesystem
Hi, I've spent last hours reading sources in the rpython directory, trying to deeper understand how lltypesystem and ootypesystem work: I've noticed that the low level representations of strings and lists are the same in both typesystem. My question is: is it a design choice or nobody has not refactored that part, yet? I think that if a target natively supports classes and other object oriented constructs probably it supports strings and sequences, too, so we should try to use these facilities as much as possible. I don't remember which people are working on ootypesystem, but if they agree I could try to refactory such things. If I have understood the source well I should begin by adding 'rlist' and 'rstr' to the list of lazily imported modules in rpython.typesystem.TypeSystem, shouldn't I? thanks for the attention ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] List and string in ootypesystem
Hi Antonio Antonio Cuni wrote: I've spent last hours reading sources in the rpython directory, trying to deeper understand how lltypesystem and ootypesystem work: I've noticed that the low level representations of strings and lists are the same in both typesystem. My question is: is it a design choice or nobody has not refactored that part, yet? Nobody has refactored this, yet. I ported rtuple to the ootypesystem last week. But I took a very simple approach, representing different types of tuples with classes. Basically, if your backend supports classes, it will automatically support tuples, too. I think that if a target natively supports classes and other object oriented constructs probably it supports strings and sequences, too, so we should try to use these facilities as much as possible. Yes, for strings, lists and dicts you want to use the facilities of the host language as much as possible. This is different from the approach I used for tuples. I had some discussion with Samuele about this, but I'm still hazy about how we should signal to the backend, that e.g. an RPython list should be replaced with a native list. Maybe Samuele can share his ideas here. Otherwise, we'll talk about it at the Leysin sprint (I'll be there on Sunday) and I'll report the results here. I don't remember which people are working on ootypesystem, but if they agree I could try to refactory such things. You are very welcome to work on this! Go ahead, people will complain if you break something. ;) But for these kinds of invasive refactorings, be sure to run the whole PyPy test suite and maybe even translation before commits. If I have understood the source well I should begin by adding 'rlist' and 'rstr' to the list of lazily imported modules in rpython.typesystem.TypeSystem, shouldn't I? Correct. But the next step after that is not clear to me at this point. But maybe you can figure something out, I don't have time to think about it right now. Cheers Nik ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] missed syncmeeting
Hi friends, I tried to get upat 6am, but didn't get my wakeup-call. Sorry, I really tried. May I just emit this: DONE: basic wrapping of RPython classes,one-way NEXT: finalizing, wrapper caching, two-way interface BLOCK: rtyping is hard to understand for special cases like this. I'm unfortunately not coming to Leysin. But I will be in Japan and Iceland. I need Japan to discuss the thread pickling problem and to get us stated on that. cheers - chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
