On Sun, Feb 24, 2013 at 7:29 PM, Ghitulete Razvan wrote:

On Sun, Feb 24, 2013 at 6:58 PM, Alex Gaynor wrote:

...

Hi,

Why are you trying to do this? The translator doesn't handle random Python, only RPython.

Alex

I am working on a research project to run python on a baremetal system. So I basically need a way of translating python code into something that can run on baremetal, hence C. After that I want to see whether it is worth it or not, and this is why I am trying to translate the benchmarks(as to have a common denominator).

Is there any way I can get threading work with the translator. That is, are there any threading implementations available in RPython code?

-- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti

Hi There is some support for threading in RPython, see rlib.rthread. RPython might not be your good buddy here. The executables built are rather large and the GC (at least on default settings) will not be that interesting for bare metal. What sort of parameters are you looking at? Also, using RPython is really tedious, you have been warned (it's *not* Python).

Have you tried cython? douwe@triposo.com | +49-(0)-1573-4469916 | @dosinga On Sun, Feb 24, 2013 at 6:48 PM, Ghitulete Razvan wrote:

On Sun, Feb 24, 2013 at 7:37 PM, Maciej Fijalkowski wrote:

...

Hi

There is some support for threading in RPython, see rlib.rthread.

RPython might not be your good buddy here. The executables built are rather large and the GC (at least on default settings) will not be that interesting for bare metal. What sort of parameters are you looking at?

Also, using RPython is really tedious, you have been warned (it's *not* Python).

Well, I don't seem to have much of a choice as I basically need source code out of python and not a binary. Also from what I see there is no translator that successfully translates full Python code into C/C++. As for parameters I don't care that much about the binary as I am not running in a resource restricted environment. I am actually running the baremetal binary on a x86_64 workstation.

-- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti

_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev

On Sun, Feb 24, 2013 at 10:10 PM, Daπid wrote:

On 24 February 2013 18:54, Douwe Osinga wrote:

...

Have you tried cython?

Another possibility is Shedskin: "an experimental compiler, that can translate pure, but implicitly statically typed Python (2.4-2.6) programs into optimized C++. It can generate stand-alone programs or extension modules that can be imported and used in larger Python programs."

https://code.google.com/p/shedskin/

It (intentionally) does not support type annotation, because they want to know how far they can go without it.

Shedskin is again, just as bad as RPython (and maybe worse)

David.

_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev

On Sun, Feb 24, 2013 at 7:58 PM, Ronny Pfannschmidt < Ronny.Pfannschmidt@gmx.de> wrote:

are you trying to write an operating system in "python"?

No, I actually want to see how fast can python code go. Writing an operating system in python would be quite crazy, and I am still rather sane. Maybe in the future though. On Sun, Feb 24, 2013 at 7:54 PM, Douwe Osinga wrote:

Have you tried cython?

Actually I haven't. I remember of reading their front page, but it doesn't say anything explicitly there about converting to C code. Now that I've taken a better look, it seems interesting enough. I'll try and check it out. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti

On Sun, Feb 24, 2013 at 8:22 PM, Ronny Pfannschmidt < Ronny.Pfannschmidt@gmx.de> wrote:

then i dont quite get why you want to use rpython - pypy+jit should do

...

Ok let me rephrase that, because I fear it might not have been clear. By saying that I do not plan to write an operating system I mean that the resulted binary will not offer facilities to other programs(the common meaning of an operating system). On the other hand, by running on baremetal I mean that there will not actually be any operating system around to offer support and all code needs to be in binary form so that it can run. So yes, you can say that the resulting binary will be an operating system that will be aimed of doing a single task(in this case running various python benchmarks).

-- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti

On Sun, Feb 24, 2013 at 3:44 PM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:

On Sun, Feb 24, 2013 at 8:22 PM, Ronny Pfannschmidt < Ronny.Pfannschmidt@gmx.de> wrote:

...

then i dont quite get why you want to use rpython - pypy+jit should do

...

Ok let me rephrase that, because I fear it might not have been clear. By saying that I do not plan to write an operating system I mean that the resulted binary will not offer facilities to other programs(the common meaning of an operating system). On the other hand, by running on baremetal I mean that there will not actually be any operating system around to offer support and all code needs to be in binary form so that it can run. So yes, you can say that the resulting binary will be an operating system that will be aimed of doing a single task(in this case running various python benchmarks).

So what I think you need is a pypy binary that can run without an os... the pypy binary needs a libc to access stuff, if you have one that you are using with other C software in your project maybe you can port pypy to it... probably a pthreads library will also be needed. What you need is to define a new platform and port the whole pypy to it... probably cross compiling from linux. I think that is how the arm port works and should be doable. -- Leonardo Santagada

On Sun, Feb 24, 2013 at 8:47 PM, Alex Gaynor wrote:

What you are doing will not generate any information about how fast Python can be. It will show you the speed of RPython or Cython on baremetal, these are *NOT* python.

I really disapprove of this language purity stuff. If it compiles, it works. If it runs it's perfect. The idea behind this attempt is to see what can be done if one removes all possible overhead. So I would not like to go down that rabbit hole. On Sun, Feb 24, 2013 at 11:14 PM, Armin Rigo wrote:

Hi Ghitulete,

So are you saying that you don't want to use CPython because it's C, and you want to try C-less alternatives, or at least things that don't use libc? Then look elsewhere. An RPython program (which is definitely something different than a Python program) is translated to C code that uses libc. Changing this would be possible, but certainly not less work than, say, changing CPython to not use the libc. Which, I seem to recall, has been done long ago in an experiment of "booting CPython".

I have never said I want to try C-less alternatives, but as to my knowledge the only common ground between CPython and C, si that part of CPython is written in C, as opposed to generating C code. What I need is to get the equivalent C code of a python program. CPython on the other hand would need to have a VM to run the bytecode in, which I not plan on doing. On Sun, Feb 24, 2013 at 9:17 PM, Leonardo Santagada wrote:

So what I think you need is a pypy binary that can run without an os... the pypy binary needs a libc to access stuff, if you have one that you are using with other C software in your project maybe you can port pypy to it... probably a pthreads library will also be needed. What you need is to define a new platform and port the whole pypy to it... probably cross compiling from linux. I think that is how the arm port works and should be doable.

I have pondered on doing that, but even though it is doable, it would require quite an effort as it would need a more complete environment than what I already have. Also, by porting pypy I would yet again get another layer between python code and hardware. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti

Hi, On Mon, Feb 25, 2013 at 10:43 AM, Armin Rigo wrote:

Hi,

The point that Alex tried to make is that if you take a random medium-sized Python program, like any of the benchmarks you wanted to use, then it is very unlikely that just by chance they happen to also be valid RPython or Cython code. In order to take a Python program that was not meant to be RPython, and turn it into RPython, for example, then you need to review and fix it completely --- it is quite an endeavour. I wouldn't call it "language purity stuff" at all. If you don't think what I'm saying here makes sense, just try.

It's not that I don't think it makes sense and I am pretty sure it will prove to be an ordeal. Also, the reason I said that I don't want to go into language purity arguments is that it is actually pretty obvious that unless you get an actual VM you cannot say that the end result is pure python as some features of the language are really hard to get when you are using a direct translation. Though I am curious as to why there isn't any `full` python code translator. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti