libera/#sicl - IRC Chatlog
Search
11:28:22
edgar-rft
reference counting is important in Scheme since there are so many references, currently it's R7RS but someday RnRs might run out of the fixnum range
11:30:59
hayley
Well, reference counting was preferred for so long in Smalltalk because activation records (i.e. the call stack) are first class objects, and die quickly. So tracing mostly just cleared out activation records.
11:32:00
hayley
I am fairly sure one can implement continuations with first-class activation records, but I forget how. At least process scheduling in Smalltalk-80 was done by swapping contexts when a timer interrupted the system.
11:32:52
hayley
Come to think of it, the current activation record is a continuation, given you stuff enough context into the record.
11:58:17
hayley
Right, it just took a while to remember that everything is stored in the activation record. Though I should check with the Blue Book...
12:13:44
beach
Interestingly, before I learned Scheme, I always thought of the stack as representing the history of the computation so far, but Scheme taught me that it represents the future of the computation, i.e., the continuation.
14:07:43
sm2n
also, apple's (relatively) new m1 arm hardware has an extension for pointer integrity tagging
14:48:33
pjb
It's ironic. Stack for "activation records" were invented by LISP on machines that didn't have stack operations and dedicated registers. Then machines got them (SP, push, pop, call, return), and now everybody puts everything in this straightjacket. Now it's clear to me that nothing should be put on that hardware stack, but to let it be used by the processor only to manage interrupts (and perhaps call/return for efficiency), but
14:48:33
pjb
everything else, parameters, results, locals, clolsures should be allocated in activation records on the heap.
14:49:25
pjb
And if you have continuation you will want to copy the PC from the hardware stack to the activation records anyways, so…
16:16:44
pjb
beach: it's a problem only for the allocation: we need to have a part of the heap that can be allocated as a stack with minimal overhead, but that can later be garbage collected as usual (and with the frame possibly moved elsewhere if needed).
16:17:48
pjb
So instead of using a link instruction that reserves space on the processor SP, you'd do that on the heap frame stack pointer.
16:19:49
pjb
It could be less, even since on return you wouldn't need to unlink, you'd just let the garbage collector do its work.
18:31:13
pjb
beach: for short-lived processes, it's basically 0 (no GC needed). ;-) it's only a concern for long-lived processes, or processes using a lot of memory (ie. probably not short-lived)... Of course, this answer assume something like unix :-/