Path: utzoo!attcan!uunet!deimos!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@oberon.csg.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: floating point formats -- usage of small floats Message-ID: Date: 5 Mar 90 16:50:28 GMT References: <3880@uceng.UC.EDU> <1990Mar5.031003.12107@Neon.Stanford.EDU> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 26 In-Reply-To: wilson@carcoar.Stanford.EDU's message of 5 Mar 90 03:10:03 GMT I don't have any references on distribution of floating point numbers (and hope you'll be able to point us to them). However, a few thoughts on "smaller-than-word" floating point: - My first reaction was that you should use one of the 20 or 24 bit floating point formats that are used by a number of DSPs - say the AT&T chip. - Second, it occurred to me that you could sacrifice the low order bit(s) of the mantissa, in much the same way that many LISP systems use the least significant bit of the integer format as a tag. If you used LSB=0 as the tag for your <32 bit tagged FP value, you wouldn't need any masking operations on the operands before dispatching the FP operation. However, you would need a cleanup afterwards, probably implementing correct rounding in software. Trouble is, the LSB=0 tag would conflict with the most convenient tag value for integers. A little bit of masking for <32 bit FP operations might be acceptable if it permitted the dynamically more frequent integer operations to have no tag manipulation overhead. You could still use the native FP hardware. A machine like the 88K, where FP and integers share the same register file, might be preferrable for you. A seperate FP register set will usually require a bit more footwork in order to perform the "integer" tag masking operations on the FP value. -- Andy Glew, aglew@uiuc.edu