From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7995 invoked by alias); 6 May 2002 21:50:39 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 7952 invoked from network); 6 May 2002 21:50:37 -0000 Received: from unknown (HELO deimos.hpl.hp.com) (192.6.19.190) by sources.redhat.com with SMTP; 6 May 2002 21:50:37 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id OAA03118; Mon, 6 May 2002 14:50:36 -0700 (PDT) Received: from hplex1.hpl.hp.com (hplex1.hpl.hp.com [15.0.152.182]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with SMTP id g46LoYJ21693; Mon, 6 May 2002 14:50:34 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Mon, 06 May 2002 14:50:33 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 14:50:33 -0700 Message-ID: <40700B4C02ABD5119F000090278766443BF294@hplex1.hpl.hp.com> From: "Boehm, Hans" To: "'Randall R Schulz'" , "Boehm, Hans" , "'tprince@computer.org'" , tromey@redhat.com Cc: "Billinghurst, David (CRTS)" , java@gcc.gnu.org, cygwin@cygwin.com Subject: RE: Object alignment, was: cygwin failures - assertion "!(addr & FLAGS)" failed: Date: Mon, 06 May 2002 14:50:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-05/txt/msg00334.txt.bz2 > From: Randall R Schulz [mailto:rrschulz@cris.com] > > Is there a reason that the three bits used for lock > management must be the > least significant three? The XSB interpreter (XSB is a Prolog > system) uses > even more bits, but doesn't demand that they be contiguous. > Depending on > the processor, machine and OS architecture, the tag bits XSB > needs (which > are classic data type tags) can be split and reassembled as needed. > Naturally, it can get costly to do this, but I assume that it > maximizes the > set of systems on which XSB can run while preserving as many bits as > possible for the actual (type-tagged) data values stored. > > Is there a reason a more flexible approach to "stolen" bits > cannot be taken > by GCJ? Not that I know of. I think it would be fairly easy to make this configurable. The code shouldn't rely on the position of those bits anyway, and I believe it doesn't. This may help with some embedded applications. Otherwise I'm not sure it would buy you much. On 64-bit processore, 8-byte alignment is generally required anyway. On 32-bit processors, I don't think you want to limit the address space any more than it already is. My guess is that allowing the code to be configured to require only 8 byte object spacing (by simply dropping the low order bits in the locking code) is a more general solution. Hans -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/