Finally, how can I check the virtual memory address for a given variable/object? Another aspect of the project I am working on requires that I am able to map memory regions from a Pyston process into kernel memory, and then externally access or modify values internal to that Pyston process (probably using mmap() from within a kernel module). Thus, being able to find exactly where in memory an object is stored would be very useful. I find that id() often returns negative values - is this still a memory address, perhaps using twos complement, or is id() not a reliable way to check addresses in Pyston?
My apologies if any of these questions are obvious or answered elsewhere already - I did search fairly extensively before asking, but I could easily have overlooked something. I am pretty new both to the world of compilers and to exploring large code bases. All help is deeply appreciated.
Our command line flags mostly follow CPython's; you can find them here:
https://github.com/dropbox/pyston/blob/master/src/jit.cpp#L184
https://github.com/dropbox/pyston/blob/master/src/jit.cpp#L184
I think you can pass the
-j flag and Pyston will spit out a .o file for each function it compiles, which you can then disassemble with objdump
Here's how
id() is defined: https://github.com/dropbox/pyston/blob/master/src/runtime/builtin_modules/builtins.cpp#L318
There was an old reason that it xor'd with a constant, which should no longer be necessary
ARM code would be awesome :) but I'm sure is a lot of work
and since things aren't being actively developed it might be hard to get help
We have two places we emit code: one is through the LLVM jit, which should have ARM support. the other is our jit (src/asm_writing), which is probably much harder to convert
got pyston running on OSX (baseline jit only at the moment) https://github.com/toshok/pyston/tree/osx-port
really, really rough at the moment.
but that shouldn't be too hard to get working
I have another quick question for you or anyone who is decently familiar with the Pyston source code. Something I am working on in my current project is extending Pyston grammar with an additional keyword. In CPython,
Python/graminit.c and Include/graminit.h are auto-generated from Grammar/Grammar when you run make.
In tracking down all the files I need to modify to implement an additional keyword in Pyston, I can’t seem to find the grammar file from which
graminit.c and graminit.h are generated. The only grammar file I can find is from_cpython/Lib/lib2to3/Grammar.txt, but modifying this does not seem to trigger a regeneration of the graminit files.
Where should I be looking for the grammar file that Pyston generates these from?
Here: https://github.com/dropbox/pyston/tree/master/src/codegen. But first you may need copy new generated CPython
Python-ast.h file. And then extend the Pyston interpreter and jit.
Again, I really appreciate all the help
and probably graminit.h/c as well
We never experimented with changing the grammar, but maybe one way to do that is to make the change in a CPython checkout, regenerate the various files, and re-copy them into Pyston
you probably need to regenerate src/codegen/cpython_ast.cpp (it includes the script to do so at the top of the file)
as I said, we haven't tried this, so I don't expect it to be super straightforward. let us know if you run into issues!
if I try to use the keyword from within a function, Pyston crashes.
in every other context, it seems to work just fine
the behavior of the keyword itself shouldn't be breaking anything, since it is just a trivial keyword for now
therefore i'm thinking maybe i need to modify Pyston's symbol table
would
src/codegen/irgen.cpp be the right place to look for this?
I'd pass
-I to the pyston process, which forces it to stay in the AST interpreter
and get that working first
-I will force it to stay in codegen/ast_interpreter.cpp and make things much simpler
if that doesn't help, it might be some of the static analysis we do; if you post the crash then I could make a more informed guess
$ ./pyston_dbg -I
Pyston v0.7.0 (rev f7e8fcf7d57c624da5ac8a8be7d0d55c260ff32e), targeting Python 2.7.8
>>
>>
>> escal x
reached an escal statement
>>
>>
>> def foo():
... escal y
... return 4
...
../../src/core/ast.h:1151: virtual bool pyston::ASTVisitor::visit_escal(pyston::AST_Escal *): Assertion `0' failed:
Someone called abort!
Aborted (core dumped)