On Mon, 11 Mar 2019 18:03:26 -0400
David Mertz wrote:
> Parrot got rather further along than rattlesnake as a register based VM. I
> don't think it every really beat CPython in speed though.
>
> http://parrot.org/
But Parrot also had a "generic" design that was supposed to cater for
all dynamic
Parrot got rather further along than rattlesnake as a register based VM. I
don't think it every really beat CPython in speed though.
http://parrot.org/
On Mon, Mar 11, 2019, 5:57 PM Neil Schemenauer
wrote:
> On 2019-02-27, Victor Stinner wrote:
> > The compiler begins with using static single a
On 2019-02-27, Victor Stinner wrote:
> The compiler begins with using static single assignment form (SSA) but
> then uses a register allocator to reduce the number of used registers.
> Usually, at the end you have less than 5 registers for a whole
> function.
In case anyone is interested on workin
Victor Stinner wrote:
Using a different register may require an explicit "CLEAR_REG R1"
(decref the reference to the builtin range function) which is less
efficient.
Maybe the source operand fields of the bytecodes could
have a flag indicating whether to clear the register
after use.
--
Greg
_
On Tue, Feb 26, 2019 at 3:56 PM Neil Schemenauer
wrote:
> Right. I wonder though, could we avoid allocating the Python frame
> object until we actually need it? Two situations when you need a
> heap allocated frame come to mind immediately: generators that are
> suspended and frames as part of
On 2019-02-27, Greg Ewing wrote:
> Joe Jevnik via Python-Dev wrote:
> > If Python switched to a global stack and global registers we may be able
> > to eliminate a lot of instructions that just shuffle data from the
> > caller's stack to the callee's stack.
>
> That would make implementing generat
Le mar. 26 févr. 2019 à 23:40, Greg Ewing
a écrit :
> Victor Stinner wrote:
> > LOAD_CONST_REG R0, 2 (const#2)
> > LOAD_GLOBAL_REG R1, 'range' (name#0)
> > CALL_FUNCTION_REG4, R1, R1, R0, 'n'
>
> Out of curiosity, why is the function being passed twice here?
Ah, I should have expla
> I uploaded a tarfile I had on my PC to my web site:
>
> http://python.ca/nas/python/rattlesnake20010813/
>
> It seems his name doesn't appear in the readme or source but I think
> Rattlesnake was Skip Montanaro's project. I suppose my idea of
> unifying the local variables and the registers
Victor Stinner wrote:
LOAD_CONST_REG R0, 2 (const#2)
LOAD_GLOBAL_REG R1, 'range' (name#0)
CALL_FUNCTION_REG4, R1, R1, R0, 'n'
Out of curiosity, why is the function being passed twice here?
--
Greg
___
Python-Dev mailing list
Python-Dev
Joe Jevnik via Python-Dev wrote:
If Python switched to a global
stack and global registers we may be able to eliminate a lot of
instructions that just shuffle data from the caller's stack to the
callee's stack.
That would make implementing generators more complicated.
--
Greg
__
METH_FASTCALL passing arguments on the stack doesn't necessarily mean it
will be slow. In x86 there are calling conventions that read all the
arguments from the stack, but the rest of the machine is register based.
Python could also look at ABI calling conventions for inspiration, like
x86-64 where
Jeroen Demeyer wrote:
Let me just say that the code for METH_FASTCALL function/method calls is
optimized for a stack layout: a piece of the stack is used directly for
calling METH_FASTCALL functions
We might be able to get some ideas for dealing with this kind of
thing from register-window arc
Le mar. 26 févr. 2019 à 21:58, Neil Schemenauer a écrit :
> It seems his name doesn't appear in the readme or source but I think
> Rattlesnake was Skip Montanaro's project. I suppose my idea of
> unifying the local variables and the registers could have came from
> Rattlesnake. Very little new i
Hum, I read again my old REGISTERVM.txt that I wrote a few years ago.
A little bit more context. In my "registervm" fork I also tried to
implement further optimizations like moving invariants out of the
loop. Some optimizations could change the Python semantics, like
remove "duplicated" LOAD_GLOBA
Let me just say that the code for METH_FASTCALL function/method calls is
optimized for a stack layout: a piece of the stack is used directly for
calling METH_FASTCALL functions (without any copying any PyObject*
pointers). So this would probably be slower with a register-based VM
(which doesn't
No, I wasn't aware of this project. My starting point was:
http://static.usenix.org/events/vee05/full_papers/p153-yunhe.pdf
Yunhe Shi, David Gregg, Andrew Beatty, M. Anton Ertl, 2005
See also my email to python-dev that I sent in 2012:
https://mail.python.org/pipermail/python-dev/2012-November/12
Yes, this should totally be attempted. All the stack manipulation opcodes
could be dropped if we just made (nearly) everything use 3-address codes,
e.g. ADD would take the names of three registers, left, right and result.
The compiler would keep track of which registers contain a live object (for
r
On 2019-02-26, Victor Stinner wrote:
> I made an attempt once and it was faster:
> https://faster-cpython.readthedocs.io/registervm.html
Interesting. I don't think I have seen that before. Were you aware
of "Rattlesnake" before you started on that? It seems your approach
is similar. Probably n
18 matches
Mail list logo
