On Aug 5, 2:09 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Regarding exploring processor instructions.
>
> Lets say you compile a C program targeting x86 architecture, with
> optimizations
> turned on for speed, and let the compiler automatic select MMX and SSE
> instructions
> for numeric
On Aug 5, 1:54 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 12:12 PM, castironpi <[EMAIL PROTECTED]> wrote:
> > On Aug 5, 9:21 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > wrote:
> >> On Aug 3, 1:26 am, castironpi <[EMAIL PROTECTED]> wrote:
>
> >> > Which is 12 bytes lo
On 5 Aug, 20:54, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
> JIT has been around for decades now, it's well documented, well
> understood, and quite common.
Apart from Psyco, whose status is hopefully that of being revived
somewhat [1], not quite common enough to permeate the most popular
Python
Regarding exploring processor instructions.
Lets say you compile a C program targeting x86 architecture, with
optimizations
turned on for speed, and let the compiler automatic select MMX and SSE
instructions
for numeric code.
I have now a program that executes very fast, and does what I want
very
On Tue, Aug 5, 2008 at 12:12 PM, castironpi <[EMAIL PROTECTED]> wrote:
> On Aug 5, 9:21 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>> On Aug 3, 1:26 am, castironpi <[EMAIL PROTECTED]> wrote:
>>
>>
>> > Which is 12 bytes long and runs in a millisecond. What it does is set
>> > a memory ad
On Aug 5, 9:21 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Aug 3, 1:26 am, castironpi <[EMAIL PROTECTED]> wrote:
>
>
> > Which is 12 bytes long and runs in a millisecond. What it does is set
> > a memory address to successive integers 0..9, then yields. Due to the
> > nature of progra
On Aug 3, 1:26 am, castironpi <[EMAIL PROTECTED]> wrote:
> On Aug 2, 2:02 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
>
> > castironpi <[EMAIL PROTECTED]> wrote:
>
> > >And furthermore, I think I'm getting
> > >confused about what exactly constitutes an interpreter: it is whether
> > >there is a pro
On Aug 2, 2:02 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
>
> >And furthermore, I think I'm getting
> >confused about what exactly constitutes an interpreter: it is whether
> >there is a process that runs product instructions, or the product
> >instructions c
On 2 Aug, 08:33, castironpi <[EMAIL PROTECTED]> wrote:
> On Aug 1, 5:24 am, Paul Boddie <[EMAIL PROTECTED]> wrote:
>
> > a + b # in Python
> >
> > ...is not sufficiently represented by...
> >
> > ldr r1, a
> > ldr r2, b
> > add r3, r1, r2
> >
> > ...in some assembly language (and the result
castironpi <[EMAIL PROTECTED]> wrote:
>
>And furthermore, I think I'm getting
>confused about what exactly constitutes an interpreter: it is whether
>there is a process that runs product instructions, or the product
>instructions can run standalone. I would take 'compiler' to mean,
>something that
Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>On Thu, 31 Jul 2008 06:17:59 GMT, Tim Roberts <[EMAIL PROTECTED]> declaimed
>the following in comp.lang.python:
>
>> And again, I never said that it did. CPython is an interpreter. the
>> user's code is never translated into machine language.
>
>
On Aug 1, 5:24 am, Paul Boddie <[EMAIL PROTECTED]> wrote:
> On 1 Aug, 07:11, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
> > Given the restrictions (or rather, freedoms) of Python, does there
> > exist code that necessarily cannot translate to machine code? In
> > other words, can you translate al
castironpi wrote:
Similarly, I take it that the decision to make CPython a stack machine
+ VM was a design decision, not a necessity, favoring internal
simplicity over the extra 5%.
Years ago, someone once started a project to write a register-based
virtual machine for (C)Python. I suspect it
On 1 Aug, 07:11, castironpi <[EMAIL PROTECTED]> wrote:
>
> Given the restrictions (or rather, freedoms) of Python, does there
> exist code that necessarily cannot translate to machine code? In
> other words, can you translate all Python code to machine code?
Given that all valid Python code can b
On Jul 31, 1:17 am, Tim Roberts <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
>
> >In C, we have:
>
> >int x, y;
> >x= 10;
> >y= x+ 1;
>
> >It translates as, roughly:
>
> >8000 .data
> >7996 #x
> >7992 #y
> >7988 .end data
> >7984 loadi reg0 7996
> >7980 loadi
Duncan Booth wrote:
Terry Reedy <[EMAIL PROTECTED]> wrote:
1. Portability: The Microsoft C# JIT compiler runs under Windows .NET
on x86/amd64 and maybe it64 and what else? Just porting .NET to run
0n Linux on the same processors was/is a bit task. Does MONO have a
JIT also?
Technically t
Terry Reedy <[EMAIL PROTECTED]> wrote:
> 1. Portability: The Microsoft C# JIT compiler runs under Windows .NET
> on x86/amd64 and maybe it64 and what else? Just porting .NET to run
> 0n Linux on the same processors was/is a bit task. Does MONO have a
> JIT also?
Technically there is no such th
in 76135 20080731 090911 Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>On Thu, 31 Jul 2008 06:17:59 GMT, Tim Roberts <[EMAIL PROTECTED]> declaimed
>the following in comp.lang.python:
>
>
>> And again, I never said that it did. CPython is an interpreter. the
>> user's code is never translated into
castironpi <[EMAIL PROTECTED]> wrote:
>
>In C, we have:
>
>int x, y;
>x= 10;
>y= x+ 1;
>
>It translates as, roughly:
>>
>8000 .data
>7996 #x
>7992 #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
castironpi wrote:
The current CPython VM does not compile code.
CPython compiles Python code to bytecode for its CPython *hardware
independent* VM using standard compiler methdods and tools (lexer,
parser, code generator, and optimizer). That VM (interpreter) is
written in portable-as-po
ng a general rule instead of a type-specific
rule. But for the time being having the DLR automatically handle this has been
working good enough for these situations.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of castironpi
Sent: Tuesday, July 29, 2008 11:40 PM
To
I note that IronPython and Python's pickle.dumps do not return the
same value. Perhaps this relates to the absence of interpreter loop.
>>> p.dumps( { 'a': True, 'b': set( ) } )
IPy: '(dp0\nVb\np1\nc__builtin__\nset\np3\n((lp4\ntp5\nRp2\nsVa
\np6\nI01\ns.'
CPy: "(dp0\nS'a'\np1\nI01\nsS'b'\np2\nc_
- www.codeplex.com/IronPython
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of castironpi
Sent: Tuesday, July 29, 2008 9:20 PM
To: python-list@python.org
Subject: Re: interpreter vs. compiled
On Jul 29, 7:39 am, alex23 <[EMAIL PROTECTED]> wrote:
>
On Jul 29, 1:46 am, Tim Roberts <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
>
> >In CPython yes. In IronPython yes: the parts that are compiled into
> >machine code are the interpreter, *not user's code*.
>
> WRONG! You are WRONG. At "compile" time, the Python code is com
On Jul 29, 7:39 am, alex23 <[EMAIL PROTECTED]> wrote:
> On Jul 29, 2:21 pm, castironpi <[EMAIL PROTECTED]> wrote:
>
> > On Jul 28, 5:58 pm, Fuzzyman <[EMAIL PROTECTED]> wrote:
> > > Well - in IronPython user code gets compiled to in memory assemblies
> > > which can be JIT'ed.
>
> > I don't believe
On Jul 29, 2:21 pm, castironpi <[EMAIL PROTECTED]> wrote:
> On Jul 28, 5:58 pm, Fuzzyman <[EMAIL PROTECTED]> wrote:
> > Well - in IronPython user code gets compiled to in memory assemblies
> > which can be JIT'ed.
>
> I don't believe so.
Uh, you're questioning someone who is not only co-author of
castironpi <[EMAIL PROTECTED]> wrote:
>
>In CPython yes. In IronPython yes: the parts that are compiled into
>machine code are the interpreter, *not user's code*.
WRONG! You are WRONG. At "compile" time, the Python code is compiled to
an intermediate language. At "run" time, the intermediate
On Jul 28, 5:58 pm, Fuzzyman <[EMAIL PROTECTED]> wrote:
> 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 c
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
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 implemen
Tim Roberts wrote:
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 lang
in 75186 20080725 050433 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 impleme
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 w
On Jul 23, 12:08 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Oh. How is the stack represented?
>
> > As usual, as successive locations in memory.
> > I have the impression that CPython uses the same stack C does.
>
> Actually, it doesn't (at least not for the evaluation stack).
>
> In CP
castironpi 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.
good thing Python don't have to listen to you,
>> Oh. How is the stack represented?
>
> As usual, as successive locations in memory.
> I have the impression that CPython uses the same stack C does.
Actually, it doesn't (at least not for the evaluation stack).
In CPython, when a Python function starts, the maximum depth of the
evaluation sta
On Jul 22, 11:38 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
> castironpi <[EMAIL PROTECTED]> wrote:
>
> >You're saying the VM can't compile code. That makes sense, it's not a
> >compiler.
>
> I wouldn't say "can't". The current CPython VM does not compile code. It
> COULD. The C#/.NET VM does.
castironpi <[EMAIL PROTECTED]> wrote:
>
>You're saying the VM can't compile code. That makes sense, it's not a
>compiler.
I wouldn't say "can't". The current CPython VM does not compile code. It
COULD. The C#/.NET VM does. IronPython, for example, is an implementation
of Python that uses .NET
On Jul 18, 2:13 pm, Dan <[EMAIL PROTECTED]> wrote:
> On Jul 18, 2:17 pm, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jul 17, 11:39 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
> > > On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
>
> > > > On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]
On Jul 18, 2:17 pm, castironpi <[EMAIL PROTECTED]> wrote:
> On Jul 17, 11:39 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
>
> > > On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
>
> > > > On Thu, 17 Jul 2008 15:08:17 -0700, castir
On Jul 17, 11:39 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
>
> > > On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> > > > The Python disassembly is baffling though.
>
> >
On Jul 18, 2:31 pm, castironpi <[EMAIL PROTECTED]> wrote:
> Given that, what does that column indicate?
Offset.
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 17, 11:39 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
>
> > > On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> > > > The Python disassembly is baffling though.
>
> >
On 18 Jul., 01:15, castironpi <[EMAIL PROTECTED]> wrote:
> On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> > > The Python disassembly is baffling though.
>
> > y= 3
> > dis.dis('x=y+1')
>
> > You can't disassemble string
castironpi wrote:
On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
Oh. How is the stack represented?
As usual, as successive locations in memory.
I have the impression that CPython uses the same stack C does.
While conceptually, CPython may put objects on the stack, I am pretty
sure it
On Jul 17, 5:37 pm, I V <[EMAIL PROTECTED]> wrote:
> On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> > The Python disassembly is baffling though.
>
> y= 3
> dis.dis('x=y+1')
>
> You can't disassemble strings of python source (well, you can, but, as
> you've seen, the results are n
On Thu, 17 Jul 2008 15:08:17 -0700, castironpi wrote:
> The Python disassembly is baffling though.
>
y= 3
dis.dis('x=y+1')
You can't disassemble strings of python source (well, you can, but, as
you've seen, the results are not meaningful). You need to compile the
source first:
>>> co
I'm curious about some of the details of the internals of the Python
interpreter:
I understand C from a hardware perspective.
x= y+ 1;
Move value from place y into a register
Add 1 to the value in the register
Move the addition's result to place x
The Python disassembly is baffling though.
>>>
48 matches
Mail list logo
