On Wed 16 May 2012 02:39, Noah Lavine noah.b.lav...@gmail.com writes:
Do you mean that the register pool will grow and shrink for each
function call? Is that why the stack frames can be fixed-size?
The register pool is the set of locals on the stack. Registers for one
function are stored in
On Wed 16 May 2012 06:23, Mark H Weaver m...@netris.org writes:
It's surprising to me for another reason: in order to make the
instructions reasonably compact, only a limited number of bits are
available in each instruction to specify which registers to use.
It turns out that being reasonably
Mark H Weaver m...@netris.org writes:
I certainly agree that we should have a generous number of registers,
but I suspect that the sweet spot for a VM is 256, because it enables
more compact dispatching code in the VM, and yet is more than enough to
allow a decent register allocator to
Hi Mark,
You are thinking along very similar lines to how I used to think. But
I have a different way to think about it that might make it seem
better.
In our current VM, we have two stacks: the local-variable stack, which
has frames for different function calls and is generally what you'd
think
Howdy,
On Wed 16 May 2012 15:44, Mark H Weaver m...@netris.org writes:
The design of the wip-rtl VM is to allow 16M registers (24-bit
addressing). However many instructions can just address 2**8 registers
(8-bit addressing) or 2**12 registers (12-bit addressing). We will
reserve registers
Hi Stefan,
On Fri 11 May 2012 22:29, Stefan Israelsson Tampe stefan.ita...@gmail.com
writes:
1. What about growing stacks any coments if they will be easier to manage
for this setup. Can one copy the C stack logic?
Having a fixed-size frame means that it's easier to have disjoint
stacks,
On Wed 16 May 2012 16:54, Noah Lavine noah.b.lav...@gmail.com writes:
In our current VM, we have two stacks: the local-variable stack, which
has frames for different function calls and is generally what you'd
think of as a stack, and the temporary-variable stack, which is
literally a stack in
Hi Andy,
Andy Wingo wi...@pobox.com writes:
Likewise I can imagine cases in which you might end up with more than
2**12 active locals, especially in the presence of macros. In that case
you spill. But where do you spill?
You spill to them to stack of course, which brings me to my next
Perhaps it needs a different name than register virtual machine.
How about RTL VM, since it's a virtual machine that interprets RTL?
Or maybe frame-addressed VM, because the operations address objects
in the current stack frame?
Noah
Hi,
Noah Lavine noah.b.lav...@gmail.com skribis:
I think what Andy is proposing to do is to get rid of the
temporary-variable stack and operate directly on the local-variable
stack. We shouldn't think of these registers as being like machine
registers, and in fact maybe registers is not a
On Mon 14 May 2012 23:28, Andrew Gwozdziewycz apg...@gmail.com writes:
On Mon, May 14, 2012 at 5:09 PM, Ludovic Courtès l...@gnu.org wrote:
Presumably the tricky part will be the register allocator, right?
The register based VMs I've seen ignore this issue by allowing for an
infinite set of
Heya Ludovic,
On Mon 14 May 2012 23:09, l...@gnu.org (Ludovic Courtès) writes:
6(local-ref 1)
8(make-int8:0)
9(ee?)
10(local-set 2) ;;
12(local-ref 2) ;; → use ‘local-set* 2’, which doesn’t pop
14
Hello,
The register based VMs I've seen ignore this issue by allowing for an
infinite set of registers. :)
Indeed, that's the plan :) The first shot at an allocator will look a
lot like the one in (language tree-il analyze).
That was a bit surprising to me. Do you mean that the register
Noah Lavine noah.b.lav...@gmail.com writes:
The register based VMs I've seen ignore this issue by allowing for an
infinite set of registers. :)
Indeed, that's the plan :) The first shot at an allocator will look a
lot like the one in (language tree-il analyze).
That was a bit surprising to
Hi Andy!
This all looks pretty exciting! Being able to get rid of all repeated
‘local-{ref,set}’ instructions sounds compelling. And it does seem to
bring us one step closer to native code.
Presumably the tricky part will be the register allocator, right?
Looking at the ‘countdown’ example, I
On Mon, May 14, 2012 at 5:09 PM, Ludovic Courtès l...@gnu.org wrote:
Hi Andy!
This all looks pretty exciting! Being able to get rid of all repeated
‘local-{ref,set}’ instructions sounds compelling. And it does seem to
bring us one step closer to native code.
Presumably the tricky part
Hi all,
This mail announces some very early work on a register VM. The code is
in wip-rtl (work in progress, register transfer language. The latter
bit is something of a misnomer.). There is not much there yet:
basically just the VM, an assembler, and a disassembler. Still, it's
interesting,
Hi,
This looks very good. i like the hole approach and this approach has the
potential to address most of the issues I have seen when disassembling
guile-2.0 output. A few notes.
1. What about growing stacks any coments if they will be easier to manage
for this setup. Can one copy the C stack
18 matches
Mail list logo
