Re: short float ???
- From: Lew Pitcher <lpitcher@xxxxxxxxxxxx>
- Date: Wed, 01 Jul 2009 11:57:50 -0400
On July 1, 2009 11:42, in comp.std.c, jacob navia (jacob@xxxxxxxxxx) wrote:
Lew Pitcher wrote:
I have similar questions that I'd like Jacob to address.
Jacob: you mention that "this format is used in the NVIDIA graphic cards,
and will be available in the x86 instruction set beginning 2010".
1) /Which/ format is "this format"?
16 bit float: 1 bit sign, 5 bits exponent, 10 bits mantissa
In which bit is the sign? What does 0 signify?
In which bits are the exponent? What range? Base?
In which bits are the mantissa? Hidden 1? What range, base?
Is the floatingpoint format used in
NVIDIA cards the /same/ format as will be available in the x86
What about other GPUs and processors that support a "short
floatingpoint" format natively?
ATI is planning a 24 bit format, but there is no date or specifications
So, we now have two competing hardware definitions for a "short float".
2) Although those specific platforms are fairly popular, they do not make
up the entirety of the C platform universe.
Can you expand on why a "short
floatingpoint" format tailored to these platforms, rather than, say, a
floatingpoint format tailored to the existing RISC or FPGA/embedded
platforms available now?
The standard should just make the provision that a short float
floating point format may be available. I have never said that it should
be an specific format.
Yet you point to two platforms on which such a format is (or will be)
supported. Why did you mention NVIDIA and Intel at all? Why couldn't
your "short float" proposal stand on it's own?
For instance "long double" can be 80 bits
(x86) or 128 bits (sparc). The standard never specifies which format
is to be used for long double, just that it should be bigger or
equal to double. In the same vein the standard should never say what
format short float should have. Just that it should be smaller or
equal than float.
Again, so why tie your proposal of a generic "short float" to NVIDIA and
3) Do you intend that C perform computations with your proposed "short
Yes of course, if not it doesn't make any sense. This supposes hardware
support. If not this format makes little sense.
So, you propose that "short float" be exempt from the pattern of promotion
rules that govern other values, and specifically the pattern of promotion
for floatingpoint numbers, where float always promotes to double ("long
float") and all floatingpoint computations (float or double) are done in
Its main objective is to provide a wide dynamic range with a small
memory footprint. NVIDIA uses this format extensively in image
brightness to accommodate the wide range available to the human eye.
It sounds like you would like the C standard to exempt "short float" from
the regular promotion rules just so that, on some platforms, it is easier
to work with hardware that provides a similar implementation. For the other
platforms, those that don't support a native small floatingpoint format in
hardware, your proposal would require that all C implementations provide
two floatingpoint math supports, one for "short float", and one for double
precision. Why should the standard support this overhead?
or will standard promotion rules apply and computations be
performed in "long float" equivalents (after promotion)? If so, then what
benefit does "short float" provide on the platforms you mentioned?
4) In a previous post, you replied (my summary, not your actual words)
that other changes to the C language that would be necessitated by your
proposed "short float" would be trivial. To me, /someone/ has to do the
actual dog-work of detailing those changes, and making a proposal as to
what the standard should say, and that /someone/ should be the person who
makes the initial "short float" proposal that initiated the changes. Are
you prepared to flesh out your proposal, including guidance on how all
those other details should look? If not, then /who/?
I will add this format as soon as it is available for the x86
platform. I will add the necessary modifications to header files
printf, scanf etc, and make a proposal.
Given your position that "short float" shouldn't/won't follow the existing
floatingpoint rules, it seems like additional language exemptions will be
necessary. Specifically, the promotion rules for variadic functions will
have to change to permit "short float" to pass through unchanged (i.e. as
an argument to printf(), etc.)
The followon changes seem to be, contrary to your opinion, non-trivial.
Again, for the purposes of formalizing your proposal, who will follow-up
with the details on the /other/ changes to the standard that "short float"
Thanks for your input
You are welcome.
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
- Prev by Date: Re: short float ???
- Next by Date: Re: short float ???
- Previous by thread: Re: short float ???
- Next by thread: Re: short float ???