A historical question

[Jerald]

Hi.

I'd like to know when python started working with bytecode.
It seems natural that in the first python implementations
code was really interpreted : executed directly.

As a result, in the first days, when the py-programmer
said:

def foo ():
print 'foo'

python stored the function body and executed it each time
foo was called. In some time it was decided to compile
this to bytecode, optimize it and call the bytecode instead.

Is it so?

I am very curious.


Gerald

[Duncan Booth]

Re: A historical question

Jerald <jfj@freemail.g r> wrote in news:chmphe$21t c$1@ulysses.noc .ntua.gr:
[color=blue]
> Hi.
>
> I'd like to know when python started working with bytecode.
> It seems natural that in the first python implementations
> code was really interpreted : executed directly.
>
> As a result, in the first days, when the py-programmer
> said:
>
> def foo ():
> print 'foo'
>
> python stored the function body and executed it each time
> foo was called. In some time it was decided to compile
> this to bytecode, optimize it and call the bytecode instead.
>
> Is it so?[/color]

According to Google, in April 1994 Guido posted complaining about some of the
inefficiencies in the bytecode interpreter:

http://groups.google.co.uk/groups?selm=9404120719.AA03729%3Dguido%40voorn.cwi.nl

I doubt very much whether there has ever been any implemention of Python that
didn't use a bytecode of some form. It would be a very perverse way to try to
write a language.

[Peter Hansen]

Re: A historical question

Jerald wrote:
[color=blue]
> I'd like to know when python started working with bytecode.
> It seems natural that in the first python implementations
> code was really interpreted : executed directly.[/color]

Why does that seem natural to you?

-Peter

[Larry Bates]

Re: A historical question

Unless I'm mistaken it is nearly impossible to
"execute" any software without translating the
source into some intermediate (read bytecode) set
of tokens and operators. All interpreters must
parse the source code and create some structured
representation (even if it is only internal) that
is normally VERY different from the source code
itself. Some interpreters never save out this
"byte code", but it exists nevertheless.

Larry Bates
Syscon, Inc.

"Jerald" <jfj@freemail.g r> wrote in message
news:chmphe$21t c$1@ulysses.noc .ntua.gr...[color=blue]
> Hi.
>
> I'd like to know when python started working with bytecode.
> It seems natural that in the first python implementations
> code was really interpreted : executed directly.
>
> As a result, in the first days, when the py-programmer
> said:
>
> def foo ():
> print 'foo'
>
> python stored the function body and executed it each time
> foo was called. In some time it was decided to compile
> this to bytecode, optimize it and call the bytecode instead.
>
> Is it so?
>
> I am very curious.
>
>
> Gerald[/color]

[Paul Watson]

Re: A historical question

"Larry Bates" <lbates@swamiso ft.com> wrote in message
news:M56dnRAyXd IUjKLcRVn-hw@comcast.com. ..[color=blue]
> Unless I'm mistaken it is nearly impossible to
> "execute" any software without translating the
> source into some intermediate (read bytecode) set
> of tokens and operators. All interpreters must
> parse the source code and create some structured
> representation (even if it is only internal) that
> is normally VERY different from the source code
> itself. Some interpreters never save out this
> "byte code", but it exists nevertheless.
>
> Larry Bates
> Syscon, Inc.
>
> "Jerald" <jfj@freemail.g r> wrote in message
> news:chmphe$21t c$1@ulysses.noc .ntua.gr...[color=green]
> > Hi.
> >
> > I'd like to know when python started working with bytecode.
> > It seems natural that in the first python implementations
> > code was really interpreted : executed directly.
> >
> > As a result, in the first days, when the py-programmer
> > said:
> >
> > def foo ():
> > print 'foo'
> >
> > python stored the function body and executed it each time
> > foo was called. In some time it was decided to compile
> > this to bytecode, optimize it and call the bytecode instead.
> >
> > Is it so?
> >
> > I am very curious.
> >
> >
> > Gerald[/color][/color]

Agreed. However, we should also consider that "compiled" excutable images
in machine language are simply bytecodes to the processor microcode.

Now... If we had a processor for which we could write microcode to execute
Python or Parrot bytecode, ...

[Carlos Ribeiro]

Re: A historical question

On Wed, 08 Sep 2004 14:20:40 -0700, Jerald <jfj@freemail.g r> wrote:[color=blue]
> I'd like to know when python started working with bytecode.
> It seems natural that in the first python implementations
> code was really interpreted : executed directly.[/color]

I assume that you expect direct execution to be the easiest way to
start implementing a new language. However, that's far from true. It's
actually pretty difficult to execut programs in procedural languages
*without* some form of intermediate code, and almost all computer
languages are compiled at some level before execution. The only
situation where direct execution makes sense is in the case of simple
command line interfaces; some simple shell script languages may be
still executed this way, but that's an exception to the rule. Even old
languages such as BASIC used to be compiled to some form of
intermediate code -- a similar concept to Python's bytecode, but much
simpler.

You may think that to create a virtual machine or compiler for a new
language is a hard task. But there is a huge body of theorethical
knowledge regarding all the pieces of software required to implement a
new computer language that can be used for this purpose. There is no
need to reinvent the wheel here. Concepts such as language parser,
intermediate code generator, optimizer, etc -- they're all quite old
and well understood. Automatic tools and code generators can be used,
given the language definition, to create a basic compiler for it. Of
course, there are a few areas with hot new advancements, but the
basics are already solidly understood.

The most dificult part is not implementing the basic compiler or
virtual machine. The hardest part is coming up with a clear and
powerful language design. That's where Python really shines.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@gmai l.com
mail: carribeiro@yaho o.com

[Peter Hansen]

Re: A historical question

Carlos Ribeiro wrote:[color=blue]
> On Wed, 08 Sep 2004 14:20:40 -0700, Jerald <jfj@freemail.g r> wrote:[color=green]
>>I'd like to know when python started working with bytecode.
>>It seems natural that in the first python implementations
>>code was really interpreted : executed directly.[/color]
>
> I assume that you expect direct execution to be the easiest way to
> start implementing a new language. However, that's far from true. It's
> actually pretty difficult to execut programs in procedural languages
> *without* some form of intermediate code, and almost all computer
> languages are compiled at some level before execution. The only
> situation where direct execution makes sense is in the case of simple
> command line interfaces; some simple shell script languages may be
> still executed this way, but that's an exception to the rule. Even old
> languages such as BASIC used to be compiled to some form of
> intermediate code -- a similar concept to Python's bytecode, but much
> simpler.[/color]

This is not, as far as I know, true. At least, not for the
general case, although certain specific implementations of
BASIC may have worked this way.

If you are thinking, for example, of how the early BASICs
on things like the Apple ][ and the PET computers worked,
you are misinterpreting (no pun intended) what actually
happened, IMHO.

The only "compilatio n" that went on was actually called
"tokenizati on", and that meant only that keywords such
as PRINT were turned into single-byte values that corresponded
directly to the keyword in the source. The rest of the
source was left as-is, including the quotation marks around
strings, variable names, etc. I think whitespace was
generally compressed (i.e. multiple spaces in places where it
wasn't syntactically meaningful were turned into one or none)
but this and the tokenization was more for memory conservation
than for anything else.

I guess one could call this "compilation".. . I wouldn't.
In fact, I think in general compilation is a process which
is not 100% reversible, whereas tokenization in the form
BASIC did it was (whitespace aside).

-Peter

[Carlos Ribeiro]

Re: A historical question

On Wed, 08 Sep 2004 11:59:38 -0400, Peter Hansen <peter@engcorp. com> wrote:[color=blue]
> Carlos Ribeiro wrote:[color=green]
> > ... Even old
> > languages such as BASIC used to be compiled to some form of
> > intermediate code -- a similar concept to Python's bytecode, but much
> > simpler.[/color]
>
> <snip>
>
> The only "compilatio n" that went on was actually called
> "tokenizati on", and that meant only that keywords such
> as PRINT were turned into single-byte values that corresponded
> directly to the keyword in the source.[/color]

You're right -- I oversimplified my explanation to reinforce the fact
that few systems ever run the program directly from the source code,
as the original poster implied in his question. Tokenization is only
the first step. But as a generic (and simple) explanation, its result
is conceptually one step closer to Python's (or Java's) bytecode than
the original (textual) program source.


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@gmai l.com
mail: carribeiro@yaho o.com

[John Bauman]

Re: A historical question


"Duncan Booth" <duncan.booth@i nvalid.invalid> wrote in message
news:Xns955E844 1C8304duncanrcp couk@127.0.0.1. ..[color=blue]
> Jerald <jfj@freemail.g r> wrote in news:chmphe$21t c$1@ulysses.noc .ntua.gr:
>[/color]
<snip original post>[color=blue]
>
> According to Google, in April 1994 Guido posted complaining about some of
> the
> inefficiencies in the bytecode interpreter:
>
> http://groups.google.co.uk/groups?se...40voorn.cwi.nl
>
> I doubt very much whether there has ever been any implemention of Python
> that
> didn't use a bytecode of some form. It would be a very perverse way to try
> to
> write a language.[/color]

From some things I read about Parrot, I'm under the impression that Ruby
(and Perl, partially) don't (yet) use bytecodes (at least internally - they
may be used as an external representation) . Instead, the program is parsed
into an abstract syntax tree and the program is interpreted by walking the
tree. See http://en.wikipedia.org/wiki/Interpreted_language . The same
method would probably work with Python.