"Samuel A. Falvo II" <
kc5tja@...> said:
>
> On Tue, 30 May 2000, Mark van Gulik wrote:
>
>> I can understand *implementing* another language in Forth, but embedding it
>> seems kind of awkward. GC in Forth is a big surprise to me. In Smalltalk I
>
> From the point of view of Forth, there is no difference between embedding
> and implementing, especially since to embed you must first implement.
Yes, to embed you must first implement. But just because a Smalltalk VM is
implemented in assembly language doesn't mean it's *embedded* in it. That
would imply that new directives were added to the assembler to support the
Smalltalk syntax, etc. Maybe we disagree on the meaning of "embed".
>> bugs in Java, I don't know how to corrupt memory with it at all. C++ with
>> GC, on the other hand, is trivial to corrupt. Simply convert a pointer to
>> integer, xor it with 0x55555555, store it somewhere, then later decode and
>> try to use it. Even with a non-moving collector, this will corrupt memory.
>
> This requires more coding time than just using a pointer directly; it's
> not economical to pull such tricks. However...
Yes, but have you seen the doubly-linked list implementation that only uses
one pointer per node? The forward and backward pointers are xored together.
When iterating (forward or backward), you must keep track of two consecutive
nodes. A simple xor will decode the next neighbour of these two in either
the forward or backward direction. An interesting technique, *impossible*
to match the space efficiency of in a (falsely) "conservatively" garbage
collected environment. Of course you could use an array of nodes and use
half-word indices into this array to implement linkages, but that's not the
point.
>> Many C++ compilers will do certain kinds of optimizations that are
>> incompatible with GC (the main example being pre-adding the address of the
>> start of an array and a constant offset that puts the address out of range
>> of the array, even though all uses of it would offset it back into range).
>
> ...this is a very good point to keep in mind and is a much more valid
> concern.
I agree that this one is more likely to be encountered.
>> I'm sure Forth has better control over these sorts of incompatible
>> optimizations, but GC? I'm skeptical of how. I could see it might be
>
> Conservative GC, the same used in C and C++ systems.
Please show me a proof (hand waving is allowed) that any Forth program which
doesn't crash without GC still will not crash when GC is present. Then I
will consider calling the garbage collector "conservative". Without that I
will call it "guessing".
Whoops, I'm in a rush right now. More later...