>>17
Yea, I'm aware of the existence of those instructions, but in
>>14's example, it led me to believe that his machine didn't have any pointer support whatsoever , nor did it have array, reference support, and you were only allowed to use cons, car and cdr.
>>18
I haven't read my SICP today, but I did read a good part of SICP a while ago. I don't see how you can avoid having plenty of overhead for storing arrays(basically what would be stored as a simple continous buffer in memory when using C-like languages) if you're only limited to cons/car/cdr and a native type such as an integer (or the type of data you're putting in an array). Yes, it's enough to implement any data structure, but for an array of n elements, you need n pointers to store them in a system only supporting cons for allocating/storing data, since each cons will have 2 pointers to your allocated data, so for n elements you'll need n pointers.
Example 1:
(cons 1 (cons 2 (cons 3 null)))
/ \
1 (cons 2 (cons 3 null))
/ \
2 (cons 3 null) ; null doesn't point anywhere
/
3
So you have 3 elements up there, and you need 3 cons's to store them, each containing 2 pointers, so you need a total of 6 pointers to store this array. In an real arch such as x86, this would mean that to store 3 32-bit integers(12 bytes), you need 9 32-bit dwords ( 36 bytes ), or 3 times the amout you'd need if you would have used a pointer. Seems a bit inefficient to me, which is why you'd need specialized datatype for storing arrays.
Note that the actual arrangement of the tree itself won't change the needed amount of memory:
Example 2:
(cons (cons 1 2) (cons 3 null))
/ \
/ \
/ \
(cons 1 2) (cons 3 null)
/ \ /
1 2 3
(6+3 = 9 dwords needed again.)