On Jul 27, 6:02 am, castironpi <[EMAIL PROTECTED]> wrote: > On Jul 24, 11:04 pm, Tim Roberts <[EMAIL PROTECTED]> wrote: > > > > > castironpi <[EMAIL PROTECTED]> wrote: > > > >Compiling a program is different than running it. A JIT compiler is a > > >kind of compiler and it makes a compilation step. I am saying that > > >Python is not a compiler and in order to implement JIT, it would have > > >to change that fact. > > > And I'm saying you are wrong. There is NOTHING inherent in Python that > > dictates that it be either compiled or interpreted. That is simply an > > implementation decision. The CPython implementation happens to interpret. > > The IronPython implementation compiles the intermediate language to native > > machine language. > > > >> of Python that uses .NET. In that case, the code *IS* JIT compiled to > > >> assembly when the program starts. > > > >But still not the user's code, only the interpreter, which is running > > >in assembly already anyway in CPython. > > > In CPython, yes. In IronPython, no; the user's code is compiled into > > machine language. Both of them are "Python". > > -- > > Tim Roberts, [EMAIL PROTECTED] > > Providenza & Boekelheide, Inc. > > In CPython yes. In IronPython yes: the parts that are compiled into > machine code are the interpreter, *not user's code*. Without that > step, the interpreter would be running on an interpreter, but that > doesn't get the user's statement 'a= b+ 1' into registers-- it gets > 'push, push, add, pop' into registers.
Well - in IronPython user code gets compiled to in memory assemblies which can be JIT'ed. Michael Foord -- http://www.ironpythoninaction.com/ -- http://mail.python.org/mailman/listinfo/python-list
