> >I don't know, but from the description "list of atoms," perhaps >numbers were represented as linked lists of bits (using the facilities >built in to support linked lists of anything).
I don't believe that any non-toy version of lisp ever used anything as ineffecient as representing numbers as lists of bits. In early lisp implementations, all data are presumed to be pointers to structures. The address space (usually 16 or 18 bits in those days) was partitioned so that some range of addresses was used to represent integers, so for example "pointers" with values 0-255 represented integers from -128 to 127. Real pointers all had values greater thatn 255. Integers ouside of the "small" range were represented by real pointers to structures whose type and organization was determinable by inspection. To do arithmetic, you'd first check (and hope for) the reserved range of addresses, then interpret the data structure to retrieve the actual values of larger integers. Perform your arithmetic, then reverse the process (including allocating memory to represent results out of the small range). With no compiler at all, as was the case in the earliest systems, this was obviously horribly ineffecient. As compiler technology improved, it gradually became true that usual cases like multiplying two integers were only 10x or so less effecient than executing on the raw hardware. Really good compilers can now do better than that. .. then of course there were lisp machines, which put all the type checking in the hardware, so ordinary arithmetic ran at full hardware speed. Symbolics lisp machines had 44 bit word size, which represented 32 bit integers directly. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
