[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] R7RS and values.

From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] R7RS and values.
Date: Thu, 3 Nov 2016 07:58:49 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 3 Nov 2016 00:16:21 +0000
>    Date: Wed, 2 Nov 2016 16:56:03 -0700
>    From: Matt Birkholz <address@hidden>
>    I do not have SVM builds working yet, but I don't expect that will be
>    a problem.  Is tools/patch.scm a problem?  Too kludgerrific?  How
>    SHOULD I train a 9.2 build host?
> [...]
> Why are you deleting expansions in SF that are already deleted from
> the source code?

I delete SF expansions in the host.  Deleting them from the source
code only removes them from the cross-compiler.

I delete them in the host so that it will generate a cross compiler
compatible with the new runtime (in which VALUES is a procedure).

> Did you change the tools build so that it doesn't actually run the
> source code of SF but still has crap from the host?

Nope.  The host's SF crap still generates the cross compiler crap, and
the crappy cross compiler includes the new (crappiest?) SF.  ?

> And what does any of this have to do with 32-bit words?

32bit heaps are too small to keep all the debugging info in
tools/  Sorry; I could have mentioned that in the commit

> One possibility is that the integrations you removed for
> (receive (x y z) (values a b c)
>   ...)
> caused some hot spot to go from moving variables around on the stack
> to allocating objects in the heap.

The old implementation of values creates a closure, on the heap.  What
variables move around on the stack?

I didn't think LIAR knew anything about whacky continuations.  Even if
it did, it wouldn't know the arity of the current continuation until
runtime, so it couldn't be generating code to magic the stack.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]