I know this was discussed earlier, but I think its still an issue.
First python's usage of values aka builtin objects:
1) almost all opcodes create a new object as result (the value)
2) LOAD_NAME | STORE_NAME (or _GLOBAL or _FAST) opcodes deal with variables, the value is fetched or stored from locals or globals.
3) objects are differently sized, an 'int' is just 3 words long
Now our POV with PMCs:
1) we need to create the LHS of almost all operations first
1a) but we don't know which PMC type is needed, so we create an Undef and morph() that to the desired PMC type
2) lexical or global ops or both for Python's weird name handling
3) as we guarantee that PMCs don't resize, the minimum PMC size is 5 words
This really doesn't fit together. We can't take advantage of the reference semantics of our opcodes. I can't emit
add a, $P0, $P1
to create the result directly in the variable 'a', because I don't know if its aliased before by 'b = a'. We have to create a new temp for the LHS and store that then.
Second is the dogma that PMCs don't resize or don't move. Python has differently sized objects. There must be a way to implement that in Parrot too.
Further: 1/ 1a) also means that we never can emulate this:
$ python Python 2.3.4 (#2, Jun 19 2004, 18:15:30) [GCC 3.3.4 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = 2 + 4 >>> b = 3 + 3 >>> a is b True >>>
- yes, these objects have the same address id(a) == id(b)
This might not be too important, Python will break it in some cases with the unification of 'int' and 'long'. But there may be other cases, were objects have to be created by the opcode (or vtable) and not beforehand.
leo
