Different byte-code in same major version (2.6.x)?

[Hartmut Goebel]

Hi,

I'm facing a curious problem: 2.6, 2.6.1 and 2.6.4 are generating
different byte-code for the same source. I can not find the reason for.

As you may know, I'm providing the 'decompyle' service as
www.crazy-comnpilers.com. This service includes verification of the
source against the original byte code. So I need to solve these kind of
differences.

This is the source:

e.args += ('xxx',)

While Python 2.6 (r26:66714, Oct 24 2008, 17:31:07) and Python 2.6.4
(r264:75706, Jan 8 2010, 18:50:31) both optimize the source and load a
tuple constant,

LOAD_NAME 'e'
DUP_TOP
LOAD_ATTR 'args'
# load a tuple constant
LOAD_CONST ('xxx',)
INPLACE_ADD
ROT_TWO
STORE_ATTR 'args'

Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
does *not* optimize:

LOAD_NAME 'e'
DUP_TOP
LOAD_ATTR 'args'
# load a string an build a tuple
LOAD_CONST 'xxx'
BUILD_TUPLE_1
INPLACE_ADD
ROT_TWO
STORE_ATTR 'args'

I checked the source in SVN and did not find any change here. But why
does this 2.6.1 generate different byte-code then? Is there anything
special about the Darwin-Build?

--
Regards
Hartmut Goebel

| Hartmut Goebel | (e-mail address removed) |
| www.crazy-compilers.com | compilers which you thought are impossible |

 

[Thomas Jollans]

Hi,

I'm facing a curious problem: 2.6, 2.6.1 and 2.6.4 are generating
different byte-code for the same source. I can not find the reason for.

As you may know, I'm providing the 'decompyle' service as
www.crazy-comnpilers.com. This service includes verification of the
source against the original byte code. So I need to solve these kind of
differences.

Do you know for certain that these builds were all compiled from the
vanilla python.org source? If the builds were created by different
distributors, patches might have been added, and these patches might
affect the byte-code generated.

This is the source:

e.args += ('xxx',)

While Python 2.6 (r26:66714, Oct 24 2008, 17:31:07) and Python 2.6.4
(r264:75706, Jan 8 2010, 18:50:31) both optimize the source and load a
tuple constant,

LOAD_NAME 'e'
DUP_TOP
LOAD_ATTR 'args'
# load a tuple constant
LOAD_CONST ('xxx',)
INPLACE_ADD
ROT_TWO
STORE_ATTR 'args'

Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
does *not* optimize:

LOAD_NAME 'e'
DUP_TOP
LOAD_ATTR 'args'
# load a string an build a tuple
LOAD_CONST 'xxx'
BUILD_TUPLE_1
INPLACE_ADD
ROT_TWO
STORE_ATTR 'args'

I checked the source in SVN and did not find any change here. But why
does this 2.6.1 generate different byte-code then? Is there anything
special about the Darwin-Build?

 

[Paul Rubin]

I'm facing a curious problem: 2.6, 2.6.1 and 2.6.4 are generating
different byte-code for the same source. I can not find the reason for.

Why should they generate the same bytecode? All that you should expect
is that the same bytecode should be runnable on all three interpreters.
It is ok if a newer version of the compiler does additional
optimizations or that sort of thing, resulting in different bytecode.
It's just like with any compiler.

 

[Hartmut Goebel]

Am 15.06.2010 20:43, schrieb Paul Rubin:

Why should they generate the same bytecode? All that you should expect

Because
a) they are only maintenance releases and changes to bytecode
generation would eb a functional change
b) bytcode-changes should change the magic-number, which is unchanged
in this case
c) there is no change to be found in SVN.

 

[Thomas Jollans]

Am 15.06.2010 20:43, schrieb Paul Rubin:

Because
a) they are only maintenance releases and changes to bytecode
generation would eb a functional change

is this python policy ? If so, references ?

b) bytcode-changes should change the magic-number, which is unchanged
in this case

isn't the code 100% compatible ?

c) there is no change to be found in SVN.

There is a difference somewhere, you just haven't found it. Maybe it's a
vendor-specific patch, maybe it's a bit of platform-specific code.

 

[Paul Rubin]

a) they are only maintenance releases and changes to bytecode
generation would eb a functional change

Why would it be a functional change, if no new bytecodes are introduced
or anything like that? I thought we were just talking about two
versions of the compiler emitting different code. It's like if gcc
4.1.3 does some optimization slightly more completely than 4.1.2, so it
emits a slightly different code sequence for some function, that does
exactly the same thing, but is a few cycles faster. For high assurance
you really have to snapshot the entire compiler.

 

[Grant Edwards]

Am 15.06.2010 20:43, schrieb Paul Rubin:

Because
a) they are only maintenance releases and changes to bytecode
generation would eb a functional change

If maintenance releases weren't allowed to produce externally visible
changes in behavior, they'd be rather pointless.

b) bytcode-changes should change the magic-number, which is unchanged
in this case

No, changes in the bytecode definitions would require a different
magic-number. As long as the different "versions" of emitted bytecode
all run on the same VM, then they all use the same majic number.

 

[Aahz]

Why should they generate the same bytecode? All that you should expect
is that the same bytecode should be runnable on all three interpreters.

....and produce the same result, modulo any bugfixes.

It is ok if a newer version of the compiler does additional
optimizations or that sort of thing, resulting in different bytecode.
It's just like with any compiler.

This seems to be a corner-case of PEP6. I think that if anyone had
specifically asked about this, I likely would have added bytecode
generation to the list of prohibitions, but there's probably little
impetus to add this prohibition to PEP6 now.