02:20 <Zarutian_HTC> hmm... am I mad to do an gc'ed object system in forth?

02:21 <Zarutian_HTC> it is on an dual stack machine where the first 32K of memory is bank switched

02:22 <Zarutian_HTC> (16 bit cells)

02:23 <Zarutian_HTC> easiest to implement is a copying compacting garbage collector

02:26 <Zarutian_HTC> each object consists of header, datacells section, and refs section

02:27 <Zarutian_HTC> each reference is two cells in size: bank and offset. And always point at the header of a object

02:29 <Zarutian_HTC> the first datacell in a object always an xt for an invocation handler for that kind of object

02:32 <Zarutian_HTC> invocations are of form: ( ... argn target_object_ref verbnr -- ...)

02:33 <Zarutian_HTC> and that is the stack which the invocation handler sees when called

02:36 <Zarutian_HTC> what is the header of an object? three things, a bit indicating that this is an object and the respective sizes of the sections of the object

02:38 <Zarutian_HTC> (the other kind of thing found in the object space is an broken heart used for gc purposes and Smalltalk80 esque become: abuse)

02:42 <Zarutian_HTC> (possibly also for post mortem finalization support too)

03:54 <tabemann> back

04:25 <proteusguy> Zarutian_HTC, I would resist gc until I found that it radically reduced complexity of my application code - RADICALLY.

15:55 <MrMobius> I think gc is good if you have a lot of interactivity

15:57 <MrMobius> redefining and deleting words eats up the dictionary so gc for words if you dont have blocks seems ideal

15:57 <MrMobius> you have to figure out what to do about ' and vectors though