Re: CPS Update

[Stefan Israelsson Tampe]

Hi,

1. Does any other system recompile stuff that set! a + operation
2. Isn't the least we should do to warn when a user set! + as I did in
the last email
3. Wouldn't it be a good idea to allow a user to specify which basic
vm op's would be translated
   to a macine instruction or not. So say that I would like to count
the number of scheme + guile uses at
   startup, then I could specify in a configuration that + should not
be comiled to a vm-op and then recompile guile and then use set!

On Sat, Feb 16, 2013 at 5:29 PM, Noah Lavine <address@hidden> wrote:
> Hello,
>
>
> On Sat, Feb 16, 2013 at 2:39 AM, Stefan Israelsson Tampe
> <address@hidden> wrote:
>>
>> Isn't the primitiveness decided by tree-il? you wil get a (<primcall>
>> ...) tree il element and then should know how to emit a
>> corresponding primitive instruction(s).
>
>
> Oh, you're right. I was thinking about that because I don't run the Tree-IL
> optimizers when I test it, so I don't get any Tree-IL primitives. Eventually
> maybe the primitive generation should happen in CPS, but I don't think it
> has to happen all at once.
>
>>
>> Anyway I think that your
>> conclusion is right, it would not make sense to support overwriting
>> these primitives dynamically, but
>>
>> scheme@(guile-user)> (set! + (lambda x (apply * x)))
>> scheme@(guile-user)> (+ 2 3)
>> $1 = 6
>> scheme@(guile-user)> (define (f x y) (+ x y))
>> scheme@(guile-user)> ,x f
>> Disassembly of #<procedure f (x y)>:
>>
>>    0    (assert-nargs-ee/locals 2)      ;; 2 args, 0 locals
>>    2    (local-ref 0)                   ;; `x'
>>    4    (local-ref 1)                   ;; `y'
>>    6    (add)
>>    7    (return)
>>
>> So things are not consistent!
>
>
> Good example! This looks like a bug to me. I think I read that loading GOOPS
> turns things like '+ into generic operations - that might be a case where
> this matters a lot.
>
> I have thought a bit about how to fix this. The module system already allows
> us to be notified whenever a variable changes, so it would be easy to watch
> all of the variables in (guile) and recompile procedures when they change. I
> might take a look at this soon.
>
>>
>> BTW
>> If you like I could work on getting define* and lambda* to work, I
>> have that code in my branch and should be able
>> to make it work on your branch as well. WDYT?
>
>
> Thanks, but I haven't even gotten far enough to think about this. I'm still
> working on getting all of the basic features going. After that I would
> definitely like define* and lambda*.
>
> Noah
>
>>
>>
>> /Stefan
>>
>> On Sat, Feb 16, 2013 at 1:53 AM, Noah Lavine <address@hidden>
>> wrote:
>> > Hello,
>> >
>> > The wip-rtl-cps branch has been rebased again (on top of wip-rtl). It
>> > now
>> > includes support for toplevel references and sets, thanks mostly to
>> > Andy's
>> > work on supporting them in RTL. (Although you shouldn't kick that part
>> > of it
>> > too hard just yet; I think I know where it will break.) Other highlights
>> > include using the top-level variable support to evaluate "(+ 3 4)"
>> > correctly.
>> >
>> > Overall, I think it's coming along well. The parts of Tree-IL that are
>> > left
>> > to implement are local mutable variables (should be easy after toplevel
>> > ones), module references and sets (very similar to top-level ones),
>> > closures, and the dynamic environment stuff. Local mutable variables are
>> > my
>> > next project, and then I think closures.
>> >
>> > One question I've had is, can we assume that the variables in the
>> > (guile)
>> > module are immutable? I think the current compiler does this. Otherwise
>> > there's no correct way to inline primitive procedures like + unless we
>> > have
>> > a way to invalidate our compiled code and recompile it (which I would
>> > like
>> > to have anyway, but that's a different story).
>> >
>> > Best,
>> > Noah
>> >
>
>