[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [r6rs-discuss] Implementors' intentions concerning R6RS
From: |
Ludovic Courtès |
Subject: |
Re: [r6rs-discuss] Implementors' intentions concerning R6RS |
Date: |
Mon, 12 Nov 2007 21:51:48 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
Hi Neil,
Neil Jerram <address@hidden> writes:
> These sound really interesting! Do we need to wait for a rewrite of
> the core interpreter, though, or could we try doing this in the
> current code?
The current code is very tricky to work with. I once tried to change
environments to use vectors instead of lists so that `scm_ilookup ()'
would become O(N), but it proved hard to do and I eventually bailed out
(IIRC the issue that stopped me had to do with rest arguments handling,
currently handled by `SCM_CDRLOC', which assumes that a frame's
variables are contained in a list, if you see what I mean).
>> * heap-allocation-free closure invocations, which can be achieved by
>> storing a closure's arguments into a stack-allocated C array or,
>> even better, in registers (of course, invoking closures with rest
>> arguments would still require allocating an argument list);
>>
>> * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
>> N is the frame number and M the position of the variable within that
>> frame's environment;
>
> Are you sure the current algorithm is O(N*M)? I would have said
> O(N+M).
Oh yes, you're right (these are two non-nested `for' loops).
>> * no C function call overhead for tail(-recursive) calls.
>
> I thought that was mostly achieved already, by extensive use of
> gotos. But I guess there must be important cases that I've not
> noticed.
You're right too. :-)
Anyway, it looks like there are opportunity for performance
improvements, and that could be an opportunity to switch to a
compiled-to-C meta-circular interpreter (as seen in SICP).
(It looks like I'm "dreaming" too much compared to my free time, but I
hope others could adopt the idea!)
Thanks,
Ludovic.