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
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'
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
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 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 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 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
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 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 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
Howdy!
On Wed 25 Apr 2012 22:39, l...@gnu.org (Ludovic Courtès) writes:
>> So, those are the problems: benchmarks running for inappropriate,
>> inconsistent durations;
>
> I don’t really see such a problem. It doesn’t matter to me if
> ‘arithmetic.bm’ takes 2mn while ‘vlists.bm’ takes 40s, since
> 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
I'm trying to port syntax-parse to master. And get into the following
trubble
(syntax-case x (integrate) ((integrate a b) ...))
fails, but
(syntax-case x (integrate) ((_ a b) ...))
does not fail
looking at the code for syntax-case I would expect that the datum integrate
is
match against and no
Hi,
Yes, I think that if one go for capturing the stack via copying frames then
that's the way
to go. This makes rewinding and unwinding fast. on the other hand,
currently in guile-log
we use very small linked frames so that essentially all the stored
information is lying in the
heap compressed to
Thx,
I have a few things I would like to do first but maybe after this weekend I
will
make the linkage!
/Stefan
On Tue, May 15, 2012 at 10:33 PM, Andy Wingo wrote:
> On Tue 08 May 2012 17:46, Stefan Israelsson Tampe
> writes:
>
> > I would like to add a link to the syntax-parse repo from guil
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
Hi!
Andy Wingo skribis:
> On Wed 25 Apr 2012 22:39, l...@gnu.org (Ludovic Courtès) writes:
>
>>> So, those are the problems: benchmarks running for inappropriate,
>>> inconsistent durations;
>>
>> I don’t really see such a problem. It doesn’t matter to me if
>> ‘arithmetic.bm’ takes 2mn while ‘
Hi Stefan,
Stefan Israelsson Tampe skribis:
> I have a few things I would like to do first but maybe after this weekend I
> will
> make the linkage!
Please add it to gnu-guile-projects.html (under template/ first, as Andy
mentioned), and using the same format as other entries there.
Thanks!
L
hi,
I'm trying to use this as a way to defined different versions of the code
depending on the
guile-version. So here it is,
(eval-when (compile load eval)
(define (ver)
(let ((v (version)))
(cond
((string-match "^2.0" v)
'v2.0)
((string-match "^2.1" v)
I have found the bug, It was because of the bug fixed in
master got a bug in my code visible!
/Stefan
-- Forwarded message --
From: Stefan Israelsson Tampe
Date: Wed, May 16, 2012 at 8:57 PM
Subject: bug in syntax-case in master
To: guile-devel
I'm trying to port syntax-parse
OK, I received a mail just now that they have acknowledged my assignment.
On Fri, May 4, 2012 at 5:15 PM, Nala Ginrut wrote:
> I've already delivered it with post. Maybe takes 1-2 weeks.
>
>
> On Thu, May 3, 2012 at 5:54 AM, Ludovic Courtès wrote:
>> Hi Noah,
>>
>> Noah Lavine skribis:
>>
>>> A
21 matches
Mail list logo
