From xemacs-m  Mon Jun 23 18:45:21 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id SAA11239
	for <xemacs-beta@xemacs.org>; Mon, 23 Jun 1997 18:45:20 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA13234 for <xemacs-beta@xemacs.org>; Mon, 23 Jun 1997 17:07:50 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id QAA20913; Mon, 23 Jun 1997 16:44:49 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA22207; Mon, 23 Jun 1997 16:44:47 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id QAA11125; Mon, 23 Jun 1997 16:44:45 -0700
Date: Mon, 23 Jun 1997 16:44:45 -0700
Message-Id: <199706232344.QAA11125@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: Yet more 64bits lossage
In-Reply-To: <kig7mfn59km.fsf@jagor.srce.hr>
References: <19970621012424.18989@iria.mines.u-nancy.fr>
	<199706210604.XAA07502@xemacs.eng.sun.com>
	<QQcuvx10888.199706210628@crystal.WonderWorks.COM>
	<199706210825.BAA07607@xemacs.eng.sun.com>
	<kigu3iss4tu.fsf@jagor.srce.hr>
	<199706211829.LAA08243@xemacs.eng.sun.com>
	<kigwwnnre7y.fsf@jagor.srce.hr>
	<199706211937.MAA08316@xemacs.eng.sun.com>
	<kig7mfn59km.fsf@jagor.srce.hr>
X-Mailer: VM 6.32 under 20.3 "Oslo" XEmacs Lucid (beta7)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz <mrb@Eng.Sun.COM> writes:
>> It might be possible to use sizeof(Lisp_Object) == 8, so that we can
>> put the gc and tag bits into the upper 32 bits, and have the complete
>> lower 32 bits available for pointers and Lisp Integers.  But you don't 
>> have to wait for Solaris 2.6 for this:
>> `long long' is available and supported today, and is of size 8.
>> As of beta 8, you can test for long long in the C source via
>> SIZEOF_LONG_LONG
>> This will be 0 unless the `long long' type is defined.

Hrv> That's nice, but is it really good behavior to use 64-bit type for
Hrv> Lisp_Object (which is used constantly throughout the code) on a 32-bit 
Hrv> OS?

Unknown.  It might make it slow, it might make it fast.  It might
depend on your compiler and your hardware.  Almost all the hardware
Sun sells today is 64-bit, so compilers ought to be able to generate
efficient long longs, or at least when supplying a compiler option
allowing the compiler to assume 64-bit hardware.  Of course, it is not 
an option to make this the default for Solaris until 64-bit hardware
is pervasive.  Until then, this kind of source modification merely has 
hack value.

Martin

>> `long long' will be part of the upcoming C standard, so starting to
>> use it now is not evil.

Hrv> I didn't know that.

