Re: Does python have the capability for driver development ?

Hi!

> Python is interpreted

No. Python is compiled (--> .pyc)
But the term "to compile" is not always unambiguous...
And the notion of "compiler" is not attached to Python (the language), but is attached to the implementation.

@+

MCI

Michel Claveau - MVP

On Jul 30, 11:10*am, Christian Heimes <li...@cheimes.de> wrote:
> Martin P. Hellwig wrote:
> > Well the pyc, which I thought was the Python bytecode, is then
> > interpreted by the VM.
>
> Python is often referred as byte-code interpreted language. Most modern
> languages are interpreted languages. The list [1] is rather long.
> Technically speaking even native code is interpreted by the micro code
> of most CPUs.
>
> [1]http://en.wikipedia.org/wiki/Interpreted_language
> [2]http://en.wikipedia.org/wiki/Microcode

Once upon a time there where lisp machines, whith processors designed
to fastly execute lisp code ... I worked with one of them for 2
years.
I wonder: has anybody thought of making a python-machine, or at least
a processor able to directly execute high-level bytecode (LLVM-like?).
I think the main feature of such a machine should be hyper-fast hash
lookup. Then dynamic memory management hardware ...

Ciao
-----
FB

Francesco Bochicchio

On Thu, Jul 30, 2009 at 3:49 AM, Francesco Bochicchio<> wrote:
> On Jul 30, 11:10Â*am, Christian Heimes <li...@cheimes.de> wrote:
>> Martin P. Hellwig wrote:
>> > Well the pyc, which I thought was the Python bytecode, is then
>> > interpreted by the VM.
>>
>> Python is often referred as byte-code interpreted language. Most modern
>> languages are interpreted languages. The list [1] is rather long.
>> Technically speaking even native code is interpreted by the micro code
>> of most CPUs.
>>
>> [1]http://en.wikipedia.org/wiki/Interpreted_language
>> [2]http://en.wikipedia.org/wiki/Microcode
>
> Once upon a time there where lisp machines, whith processors designed
> to fastly execute lisp code Â*... I worked with one of them for 2
> years.
> I wonder: has anybody thought of making a python-machine, or at least
> a processor able to directly execute high-level bytecode (LLVM-like?).
> I think the main feature of such a machine should be hyper-fast hash
> lookup. Then dynamic memory management hardware ...

Yes, it was considered a decade ago:
http://mail.python.org/pipermail/pyt...ne/004451.html

Cheers,
Chris
--
http://blog.rebertia.com

Chris Rebert

Martin P. Hellwig wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Michel
> Claveau - MVP wrote:
>> Hi!
>>
>>> Python is interpreted
>>
>> No. Python is compiled (--> .pyc)
>> But the term "to compile" is not always unambiguous...
>> And the notion of "compiler" is not attached to Python (the
>> language), but is attached to the implementation.
>>
>> @+
>>
>> MCI
>
> Well the pyc, which I thought was the Python bytecode, is then
> interpreted by the VM.
>
As Michel says, "to compile" is not always unambiguous. My definition
includes a one-way transformation from human-readable source text into
something that can be more efficiently interpreted by other code, or by
hardware. The compiler really doesn't care whether the machine it's
targeting is real or virtual.

The CPython implementation of Python compiles the source text into a
bytecode file, with extension .pyc. That certainly is a compilation
step. Followed (much) later by an interpreted one.

To pick a specific implementation of C++, Microsoft C++ compiles C++
source text into an "executable file," with extension .exe (I'm
ignoring little details, like the linker). That's a compilation step.
Then the exe file is (later) interpreted by the microcode on the Pentium
chip.

As far as I know, nobody has yet built a microcode implementation of a
Python VM (Virtual Machine). Nor have I seen one for the Java VM.
However, in the early 80's there was a microcode implementation of the
P-system VM. It was never a commercial success, but it existed. And
there have been at least three Forth machines, where the hardware itself
was designed to support the language's VM. No microcode at all.

DaveA

Dave Angel

Martin P. Hellwig wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Dave
> Angel wrote:
> <cut definition/interpretation of compiling>
> Ah yes, we thread on the territory of word definition and difference
> in interpretation. Any argument is doomed to fail if not agreed or at
> least taken in perspective of the terminology used by users.
>
> I could be (well it is quite likely) wrong in my interpretation of the
> terminology, but here goes it anyway:
>
> Machine Code:
> Whatever the machine executes, it could be that the CPU uses an
> abstraction of microcode to do this but from the perspective of the
> user, this is all done in the same 'black box'
>
> Compiling:
> Translate words/symbols/mnemonics to machine code, which than can be
> either loaded, linked and executed by an OS or read and executed by
> the BIOS.
>
> Interpreted:
> Instructions which can be fed to a previous compiled program that is
> able to dynamically change its execution and flow without the need to
> recompile itself.
>
Depending on the level of understanding of the user, plus his history
and his biases, he will include more or less in his "black box." In the
old days, microcode was not "on-chip" but stored separately in control
memory. And on many machines, it was changeable at will.

To many users these days, the entire system including software is a
black box, which gradually breaks down (gets slow, runs out of space,
crashes a lot) and must be replaced. They don't distinguish operating
system from application, real memory from virtual, or viruses from
bugs. But of course those users wouldn't be participating in this
discussion.

My background includes specifying hardware instruction sets and
architecture. And writing microcode for multiple machines. And writing
parts of compilers, interpreters, assemblers, and so on. And
microcoding interpreters. And hooking into compilers to modify how they
would generate code. And hooking into runtimes to test running code in
realtime.

So I tend to have very flexible definition of compiler and interpreter.
Probably the only reason I jumped in here was the unmentioned bias that
somehow a compiler is superior to an interpreter.

I think I'd better extend my definition of compilation. It's a step
that's statically taken over a series of instructions (not necessarily
text source), that transforms it into a form closer to the targeted
enviromment, real or virtual. Most C++ compilers have two compilers
operating serially, the first to turn the source code into an
intermediate form (like byte code), and the second to generate what is
commonly called "machine code." The second part of course is duplicated
for each different target processor.

So Java is compiled into byte code, and the typical java VM then
compiles that piecewise into machine code (so called JIT compiling, for
just in time).

BTW, interpreters don't have to be written in a compiled language.


Anyway, I don't object to your definitions. We all have different
perspectives.

DaveA

Dave Angel

Dave Angel wrote:
[snip]
> As far as I know, nobody has yet built a microcode implementation of a
> Python VM (Virtual Machine). Nor have I seen one for the Java VM.
> However, in the early 80's there was a microcode implementation of the
> P-system VM. It was never a commercial success, but it existed. And
> there have been at least three Forth machines, where the hardware itself
> was designed to support the language's VM. No microcode at all.
>
There's Jazelle: http://en.wikipedia.org/wiki/Jazelle.

MRAB

Ben Finney wrote:
> "Martin P. Hellwig" <> writes:
>
>> Machine Code:
>> Whatever the machine executes, it could be that the CPU uses an
>> abstraction of microcode to do this but from the perspective of the
>> user, this is all done in the same 'black box'
>
> This requires, of course, defining what is the machine. Python bytecode
> targets a virtual machine that is implemented differently for each
> hardware platform.
>
>> Compiling:
>> Translate words/symbols/mnemonics to machine code, which than can be
>> either loaded, linked and executed by an OS or read and executed by
>> the BIOS.
>
> Related to the above point, the “machine code� can just as easily be
> codes for a virtual machine specification. This is the case for the
> bytecode instructions Python gets compiled to.
>
>> Interpreted:
>> Instructions which can be fed to a previous compiled program that is
>> able to dynamically change its execution and flow without the need to
>> recompile itself.
>
> This doesn't make much sense to me, I must say.
>
> I'd say, instead, that a program is interpreted if its instruction are
> dynamically translated to underlying platform instructions at execution
> time. This is the case for the bytecode instructions interpreted by the
> Python virtual machine.
>
Interpretation doesn't necessarily mean translating to machine code at
execution time. What you're describing is more like JIT.

MRAB

Ben Finney wrote:
> "Martin P. Hellwig" <> writes:
>
>
>>Machine Code:
>>Whatever the machine executes, it could be that the CPU uses an
>>abstraction of microcode to do this but from the perspective of the
>>user, this is all done in the same 'black box'
>
>
> This requires, of course, defining what is the machine. Python bytecode
> targets a virtual machine that is implemented differently for each
> hardware platform.
>
>
>>Compiling:
>>Translate words/symbols/mnemonics to machine code, which than can be
>>either loaded, linked and executed by an OS or read and executed by
>>the BIOS.
>
>
> Related to the above point, the “machine code” can just as easily be
> codes for a virtual machine specification. This is the case for the
> bytecode instructions Python gets compiled to.
>
>
>>Interpreted:
>>Instructions which can be fed to a previous compiled program that is
>>able to dynamically change its execution and flow without the need to
>>recompile itself.
>
>
> This doesn't make much sense to me, I must say.
>
> I'd say, instead, that a program is interpreted if its instruction are
> dynamically translated to underlying platform instructions at execution
> time. This is the case for the bytecode instructions interpreted by the
> Python virtual machine.
>

I would have said compiled is executed by hardware, interpreted is
executed by software -- but I like your definition better.

~Ethan~

Ethan Furman

Francesco Bochicchio wrote:

> I wonder: has anybody thought of making a python-machine, or at least
> a processor able to directly execute high-level bytecode (LLVM-like?).

In some of my idle moments I've speculated on what such
a machine might be like. One of my ideas for potential
future projects is to flesh out the design and maybe even
build an FPGA prototype.

It would purely be for fun, though. It's unlikely that
such a processor would be able to compete speed-wise
with a general-purpose CPU running a Python interpreter
with critical libraries written in C.

That's what killed things like the Lisp machine. Their
developers couldn't keep up with the huge resources that
people like Intel and Motorola had to throw at CPU
development, so eventually a general-purpose CPU could
run Lisp faster than a Lisp machine.

--
Greg

greg

On Sun, 02 Aug 2009 14:19:45 +1200, greg wrote:

> That's what killed things like the Lisp machine. Their developers
> couldn't keep up with the huge resources that people like Intel and
> Motorola had to throw at CPU development, so eventually a
> general-purpose CPU could run Lisp faster than a Lisp machine.

When you say "eventually", I think you mean "decades ago". I recall a
collaboration between Apple and Texas Instruments to build a Macintosh
with a Lisp Machine in the late 1980s. From the one box, you could run
two computers simultaneously, with two operating systems, one running the
Motorola 68020 and the other a Lisp Machine processor.

I don't think it sold very well -- by memory, benchmarks showed that for
half (or less) of the price, you could run Lisp in software on a vanilla
Mac and the software would be faster than running it on the Lisp Machine.

TI also had at least one Nubus card for the Mac running a Lisp Machine:
http://en.wikipedia.org/wiki/TI_Explorer

On a similar note, there were Forth machines also available for the Apple
Macintosh. Unlike Lisp, I think they suffered from the general lack of
popularity of Forth rather than lack of speed.



--
Steven

Steven D'Aprano