Re: Does python have the capability for driver development ?

Discussion in 'Python' started by Michel Claveau - MVP, Jul 30, 2009.

  1. 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, Jul 30, 2009
    #1
    1. Advertising

  2. Python processors? : WAS Re: Does python have the capability fordriver development ?

    On Jul 30, 11:10 am, Christian Heimes <> 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, Jul 30, 2009
    #2
    1. Advertising

  3. Michel Claveau - MVP

    Chris Rebert Guest

    Re: Python processors? : WAS Re: Does python have the capability fordriver development ?

    On Thu, Jul 30, 2009 at 3:49 AM, Francesco Bochicchio<> wrote:
    > On Jul 30, 11:10 am, Christian Heimes <> 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/python-list/1999-June/004451.html

    Cheers,
    Chris
    --
    http://blog.rebertia.com
    Chris Rebert, Jul 30, 2009
    #3
  4. Michel Claveau - MVP

    Dave Angel Guest

    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, Jul 30, 2009
    #4
  5. Michel Claveau - MVP

    Dave Angel Guest

    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, Jul 30, 2009
    #5
  6. Michel Claveau - MVP

    MRAB Guest

    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, Jul 30, 2009
    #6
  7. Michel Claveau - MVP

    MRAB Guest

    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, Jul 30, 2009
    #7
  8. Michel Claveau - MVP

    Ethan Furman Guest

    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, Jul 30, 2009
    #8
  9. Michel Claveau - MVP

    greg Guest

    Re: Python processors? : WAS Re: Does python have the capabilityfor driver development ?

    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, Aug 2, 2009
    #9
  10. Re: Python processors? : WAS Re: Does python have the capabilityfor driver development ?

    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, Aug 2, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leon
    Replies:
    4
    Views:
    318
  2. Replies:
    0
    Views:
    309
  3. MalC0de
    Replies:
    9
    Views:
    1,494
    John Nagle
    Aug 10, 2009
  4. James Kanze
    Replies:
    1
    Views:
    188
    Ian Collins
    Apr 30, 2013
  5. Replies:
    1
    Views:
    75
    Öö Tiib
    May 4, 2014
Loading...

Share This Page