On 14 March 2017 at 11:17, John Zhang <john.zh...@anu.edu.au> wrote: > Hi all, > Can anyone does the favour for me by explaining the story of RuntimeTypeInfo > in RPython?
Hi John! The RTTI are a hook that the backend can implement, there is a fair bit of flexibility in what values they can take. The hooks in the C backend live here: https://bitbucket.org/pypy/pypy/src/699382943bd73bf19565e996d2042d54e7569e31/rpython/translator/c/gc.py?at=default&fileviewer=file-view-default#gc.py-145 This class is one example of a node for an RTTI value. In this one, the RTTI value is a function that can statically deallocate structs of this type. There are more in this file, for example the RTTI for a struct in a framework GC is just an identifier iiuc. I think you want to translate your opaque types yourself, possibly > I couldn’t quite understand the description on the online documentation > (http://rpython.readthedocs.io/en/latest/rtyper.html#opaque-types). From > looking at the source code, and inspecting the generated C source, RTTI > doesn’t seem to be used at all at runtime. The generated C source seems to > just return an uninitialised function pointer on the stack when compiling > the following code: > > from rpython.rtyper.rclass import OBJECTPTR > class A: > pass > > class B(A): > pass > > def f(a): > obj = rffi.cast(OBJECTPTR, a) > return lltype.runtime_type_info(obj) > > t = Translation(f, [A], backend='c') > t.backendopt(mallocs=True) > t.view() > lib = t.compile() > This example (which uses the refcount GC) grabs a function from the type OBJECTPTR that can de-allocate an OBJECTPTR (that is, it can decrement the refcount of the object `a`). I haven't had a look at why it would be uninitialised. > We were looking at RTTI in finding a solution to the loss of type > information problem at JIT encoding. My collaborators are trying to develop > a JIT back-end targeting a micro virtual machine (Mu). It seems that by > default the JIT transformer throws away the actual type information > (GcStruct etc., which is not representable under RPython, I know) and only > keeps the size. However, in Mu, memory allocation requires specific type > information. Thus, among other ways, we are trying to see how much we can > recover this object layout/type information. RTTI seems promising based on > the description on the documentation, but I can’t picture what it looks like > at run time. > Can anyone provide some insight on this? > The low-level allocation operations specify size as an operand - it might be better for you to translate the various new_ operations into a form you can make use of long before jitcode generation. You'll need to extend the codewriter to allow for those operations, too. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely MAY reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to DENY YOU THOSE RIGHTS would be illegal without prior contractual agreement. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
