castironpi <[EMAIL PROTECTED]> wrote: > >In C, we have: > >int x, y; >x= 10; >y= x+ 1; > >It translates as, roughly: >> >8000 .data >7996 ffffffff #x >7992 ffffffff #y >7988 .end data >7984 loadi reg0 7996 >7980 loadi reg1 7992 >7976 loadi reg2 10 >7972 loadi reg3 1 >7968 storv reg2 reg0 >7964 add reg0 reg1 reg2 >7960 storv reg3 reg1
I don't recognize that assembly language. Is that another intermediate language? >You are telling me that the same thing happens in IronPython. Yes, the same process happens. >By the >time the instruction pointer gets to 'x= 10', the next 7 instructions >are the ones shown here compiled from C. I most certainly did NOT say that, as you well know. Different C compilers produce different instruction sequences for a given chunk of code. Indeed, a single C compiler will produce different instruction sequences based on the different command-line options. It's unreasonable to expect a Python compiler to produce exactly the same code as a C compiler. However, that does disqualify the Python processor as a "compiler". >CMIIW, but the CPython implementation -does- -not-. And again, I never said that it did. CPython is an interpreter. the user's code is never translated into machine language. >My point is, CPython takes more than seven steps. My question is, >does IronPython? So, if compiler B isn't as good at optimization as compiler A, does that mean in your mind that compiler B is not a "compiler"? -- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
