CLIM mail archive
[Prev][Next][Index][Thread]
Re: reducing time overhead of text display (in 1.1)
Date: Wed, 22 Dec 1993 14:34 -0500
From: Scott McKay <SWM@STONY-BROOK.SCRC.Symbolics.COM>
Date: Wed, 22 Dec 1993 14:25 EST
From: lgm@iexist.att.com
Date: Wed, 22 Dec 1993 13:27 -0500
From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
Believe it or not, CLIM has a compile-time conditional that allows the
CLIM implementor to choose between three types of coordinates: T,
SINGLE-FLOAT, and FIXNUM. Right now, CLIM uses T. T and SINGLE-FLOAT
work equally well in Genera, but CER and I verified that using
SINGLE-FLOAT is a dog under Allero (and probably Lucid, too) because it
guarantees that you have to cons, whereas when CLIM uses T, CLIM often
manages to use fixnums. CLIM 1.1 always used FIXNUM, but I never quite
finished debugging the FIXNUM case in CLIM 2.0.
Some implementations have a SHORT-FLOAT that doesn't cons. Perhaps
CLIM could use SHORT-FLOAT internally whenever it's available.
The range of SHORT-FLOAT is allowed to be too small for some things.
Portably speaking, that is true. Page 20 of CLtL2 says that a
SHORT-FLOAT could have an exponent of only 5 bits (i.e., exponents up
to about +16, and hence values up to about +6s4). But since you were
speaking of a compile-time conditional anyway, I was suggesting that a
CL implementation that has non-consing SHORT-FLOATs with, for example,
8-bit exponents (i.e., exponents up to about +128, and hence values up
to about +3s38) might wish to use SHORT-FLOAT internally in CLIM.
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@iexist.att.com
Standard disclaimer.
References:
Main Index |
Thread Index