Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!think!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.misc Subject: Re: Pointers as 3-tuples (Re: JLG's flogging of horses (was Re: Relationship between C and C++)) Message-ID: <35608@think.Think.COM> Date: 14 Apr 90 05:28:16 GMT References: <20079@megaron.cs.arizona.edu> <14330@lambda.UUCP> Sender: news@Think.COM Reply-To: barmar@nugodot.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 33 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 , and lisp-array objects are implemented (by hardware and microcode) as tuples . 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