From owner-freebsd-arch@FreeBSD.ORG Tue Mar 28 10:57:25 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0651D16A401 for ; Tue, 28 Mar 2006 10:57:25 +0000 (UTC) (envelope-from andrew@areilly.bpc-users.org) Received: from omta01sl.mx.bigpond.com (omta01sl.mx.bigpond.com [144.140.92.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F22343D46 for ; Tue, 28 Mar 2006 10:57:24 +0000 (GMT) (envelope-from andrew@areilly.bpc-users.org) Received: from areilly.bpc-users.org ([141.168.4.160]) by omta01sl.mx.bigpond.com with ESMTP id <20060328105723.JKOM25377.omta01sl.mx.bigpond.com@areilly.bpc-users.org> for ; Tue, 28 Mar 2006 10:57:23 +0000 Received: (qmail 89091 invoked by uid 501); 28 Mar 2006 10:58:33 -0000 Date: Tue, 28 Mar 2006 21:58:33 +1100 From: Andrew Reilly To: Poul-Henning Kamp Message-ID: <20060328105833.GE87799@gurney.reilly.home> References: <20060328100735.GA87799@gurney.reilly.home> <61635.1143542346@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61635.1143542346@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: Jason Evans , freebsd-arch@freebsd.org Subject: Re: Proposed addition of malloc_size_np() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 10:57:25 -0000 On Tue, Mar 28, 2006 at 12:39:06PM +0200, Poul-Henning Kamp wrote: > Nope, not even close. > > What Recursiv did was novel in that the objects lived in hardware > and microcode, there were no way to overrun an array, because you > simply couldn't index it outside it's bounds. Not even in the > operating system. How is that different from all of the preceding segmented machines like (to quote your .sig) the Z8001+MMU? (Or, later, the i286). (Besides associating a type tag with the segment, which is something that lisp and smalltalk machines did.) > The fact that all objects were referenced by their object ID also > meant that they could be put or moved anywhere convenient, with > all references being by ID, it would be found when needed. A segment ID doesn't seem to be too radically different from an object ID. You can't access outside the bounds of the segment on most segmented architectures, and you can put them or page them wherever you like, because it's the segment descriptor that tells you where in physical memory the segment is, not the segment ID. Application code can't get to see that. > It obviously comes with a significant performance penalty, not > unlike page table lookups. Amusingly, just as for SOAR, modern efforts covering most of the same ground (JVM, .NET) are starting to show that you can do better in software and simple hardware than you can with complicated hardware. I'm not sure why that is still true in this day where processor architects have more transistors than they know what to do with... -- Andrew