[discuss] RFC: Support IEEE 754R draft in the x86-64 psABI

Cornea, Marius marius.cornea at intel.com
Fri May 19 20:33:07 CEST 2006

My model for decimal processing may not be flawed at all once IEEE 754R
decimal floating-point arithmetic starts being used in databases and all
the other applications you mentioned. From that point on decimal data
may just be stored in decimal format as specified by 754R, and then
conversion times to/from string will become irrelevant - fast arithmetic
will be important instead. My point is that once (and if) proprietary
decimal computation packages are replaced by IEEE 754R decimal
floating-point arithmetic, so will their proprietary storage formats
shortly thereafter.

-----Original Message-----
From: Mike Cowlishaw [mailto:MFC at uk.ibm.com] 
Sent: Friday, May 19, 2006 11:07 AM
To: Cornea, Marius
Cc: discuss at x86-64.org; Menezes, Evandro; Cornea, Marius; Michael Matz
Subject: RE: [discuss] RFC: Support IEEE 754R draft in the x86-64 psABI

Marius wrote:

> I see ASCII string-to-decimal conversions important mainly for decimal
> floating-point constants at compile time, and the opposite conversion
> for printing decimal floating-point results. 

Marius, your model of decimal processing is badly flawed.  Virtually all

decimal data in databases today are in a decimal format (Oracle Numbers,

ASCII, MySQL strings, BCD, IBM DB2, etc.).  There are vast numbers of 
telemetry and instrumentation applications where numerical data are 
exchanged in a decimal (typically ASCII) format.  The JDBC interface in 
Java uses only the String constructor and the reverse interface to 

These are the data that decimal floating-point has been designed to work

with and for.  Fast conversion of decimal data to and from the DFP
is essential; without it, having fast arithmetic is close to worthless.


More information about the discuss mailing list