🚀 go-pugleaf

In article <14330@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>On any machine (even segmented ones) the memory model presented to
>the user code is a contiguous memory address space.

Not on the machine I use, a Symbolics Lisp Machine.  The memory model
presented to user code is object-oriented.  It's possible to get actual
numeric memory addresses for objects, but these are almost useless outside
low-level implementation routines as objects may move around in memory as a
result of garbage collection.

In fact, this whole 3-tuple thing is not just an academic discussion; it is
actually used in the Symbolics C implementation.  A C pointer is
implemented (in software) as a pair <lisp-array, offset>, and lisp-array
objects are implemented (by hardware and microcode) as tuples <type, base,
dimensions, other-stuff>.  The array reference instructions perform bounds
checking in parallel with the memory reference so there's very little
overhead.  They *could* implement bounds checking of pointer arithmetic,
but they haven't; it will detect most attempts to indirect through pointers
that exceed their bounds (the one case where it doesn't is with pointers to
automatic data -- all the automatic variables in an activation record are
stored in one lisp-array, so it will only detect attempts to reference
outside the stack frame to which the pointer points, and thus the yucky

	int *p, a, b, c;
	for (p=&a; p++; p<=&c) ;

will probably "work").

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar