Lisp like lists and a problem with TANGO fromStringz

[Bjoern]

bearophile schrieb:
> Bjoern:
>> z = cast(CONS *) malloc(CONS.sizeof);
> 
> Suggestion 1: all those malloc will slow your code down, and on 32 bit CPU they burn more than 8 bytes for each cons. So I suggest you to manage a free list of them, allocating them at blocks, for example of about 64 kb. This reduces memory used, speeds up the allocation/deallocation, and may increase cache locality of your cons cells pointers a little too.
> 

Thanks bearophile,
well I thought 1) make it work then make it fast.

I'll pick up your idea. I recall that Uwe Salomon uses this technic in 
his Indigo container library. I'll have a look.

> Suggestion 2: I don't fully understand yet how the GC heap interacts with the C heap, so the following may lead to GC problems. You can allocate those memory blocks from the C heap instead of the GC heap (then you may want to add a root for each externally given pointer, this may be a bit messy). The C malloc gives you an aligned memory block, so all cons structs have an address aligned to 8/16 bytes too. So you have one or more bits free into the pointers. So you can use your cons cells to represent far more than just pairs of pointers, like chars, symbols, not-too-much-short integers, almost-floats, short strings (just need their length, that is small. Small strings are very common), etc. Many Lisp implementations use such tagged data, this reduces pointer deferences and memory use. The problem is that this is dynamic typing, so such cons become a kind of box/variant (and this isn't too much bad, I think).
> 
Yes,  could lead to problems, I think. So I will re-read Walters memory 
management article. HTH to understand.

The source compiles now. using dmd 1.025 but the output is not as 
expected. Maybe this is a GC problem. Dunno yet. I've attached the 
source. Hope you have a look.

> [Unrelated question: why aren't D dynamic arrays triples of values? So they can store their actual length and the memory they have available, so they can support  something like the reserve() of C++ STL. Is the GC already storing such third value? But then I haven't found a reliable way to perform a reserve-like operation.]
> 

If YOU don't know it .... :)

> Bye,
> bearophile

Ah, the joy of Sunday afternoon programming .. Bjoern

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lisplist.d
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20080302/09e27559/attachment.ksh>