Hi,
Noah Lavine 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 good name for these
> 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
On Wed 16 May 2012 18:27, Mark H Weaver writes:
> What's your plan for saving and restoring such a large register file?
Here it's clear that I didn't communicate well. What I am terming a
"register" is a value in a local stack slot. That's all. No need to
save and restore, since they're alrea
Hi Andy,
Andy Wingo 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 point:
as discusse
On Wed 16 May 2012 16:54, Noah Lavine 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 the sense that you
Hi Stefan,
On Fri 11 May 2012 22:29, Stefan Israelsson Tampe
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, since a register VM addre
Howdy,
On Wed 16 May 2012 15:44, Mark H Weaver 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 253 to 2
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
Mark H Weaver 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 generate good code
Hi Andy!
Andy Wingo writes:
> On Wed 16 May 2012 06:23, Mark H Weaver 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
On Wed 16 May 2012 06:23, Mark H Weaver 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 compact isn'
On Wed 16 May 2012 02:39, Noah Lavine 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 the stack frame.
Andy
Noah Lavine 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 me. Do yo
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 regis
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
> 1
On Mon 14 May 2012 23:28, Andrew Gwozdziewycz writes:
> On Mon, May 14, 2012 at 5:09 PM, Ludovic Courtès 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 registers. :)
Indee
On Mon, May 14, 2012 at 5:09 PM, Ludovic Courtès 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 will be t
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
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 log
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,
20 matches
Mail list logo
