Conference turris::languages

    In general, you can't fulfill a "promise" of 16 decimal digits with
    D_floating.  You need to analyze the real needs of your application,
    to see what promises need to be made.  It may turn out that packed
    decimal is the best data type for your application, in spite of its
    slowness in recent CPUs.  In that case, you may have to avoid the
    CPUs that run packed decimal slowly.
    
    Alternatively, it may be that D_floating provides what your application
    needs, and no rounding or truncation of the result is required.
    
    If binary floating point meets your needs but D_floating doesn't
    provide enough precision, consider H_floating.  It provides 112
    fraction bits.
    
    VAX COBOL has routines to multiply and divide quadwords.  I don't
    remember their entry point names, but they're in the VMS RTL.
        John Sauter

    
>    VAX COBOL has routines to multiply and divide quadwords.  I don't
>    remember their entry point names, but they're in the VMS RTL.

    Yup.  But they're not documented.  (They used to be, a long time ago...)
    If you want to use them, you should probably talk to us and the language 
    RTL people.
 

>    VAX COBOL has routines to multiply and divide quadwords.  I don't
>    remember their entry point names, but they're in the VMS RTL.

    Yup.  But they use the packed instructions to do it.  Or at least they
    used to.  Maybe that got changed in V4.0.

    Another possibility is to use double precision floating point to
    represent integers and maintain a scale on the side.  That's how
    a DECsystem-10 compiler I worked on faked out packed decimal.
    Of course, you'll still run into some rounding problems with
    division, but I don't think they're as bad.

    BLISS-32 has builtins that make quadword integer arithmetic a SMOP
    (ADDM, SUBM, EMUL, EDIV).

Thanks for all the input!

We've decided to opt for dual floating formats: D-float and H-float.  The
default float will be D-float with H-float available as a (much slower)
run time option for customers needing more than the 15 digits of accuracy
offered with D-float.  I'm trusting D-float to 16 digits and rounding to
15 based on the value of the 16th.

I'm using a home brew of routines to convert back and forth between ascii
and D-float (for greater efficiency), and RTL routines to handle H-float 
conversion.

A couple of questions:

1) Which machines don't emulate H-float instructions?

For floating point jockeys:

2) Is the following valid to extract the fraction digits from a D-float?

	EMODD  #1.,#0.,d_float_data,integer_part,fraction_part

LOOP:	;loop to stack fraction digits in D10E9 radix
	EMODD  #1000000000.,#0.,fraction_part,-(SP),fraction_part
	SOBGTR	count,LOOP

The OTS conversion routine uses a different technique.  I want to be
sure that the above method doesn't taint the fraction in any way.


thanks again!

marty belliveau
DSM engineering group

The OTS group cannot use EMODx because this instruction has been placed
in the Emulated-Only Instruction Group (see section 11.1.3 of DEC STD 32).
Digital software should avoid using such instructions because they will
have very poor performance on future VAX implementations.

Which machines have H-float is described in Appendix B of DEC STD 32.

>We've decided to opt for dual floating formats: D-float and H-float.  The
>default float will be D-float with H-float available as a (much slower)
>run time option for customers needing more than the 15 digits of accuracy
>offered with D-float.  I'm trusting D-float to 16 digits and rounding to
>15 based on the value of the 16th.
>
>Which machines don't emulate H-float instructions?

     Don't you have to find out which machines emulate floating point and 
which ones emulate decimal?  For any machine thats out there that 
implements decimal but emulates floating point, your application will run 
slower. 

     What was wrong with the multiple precision integer approach 
[discussed via MAIL], with which decimal string operations would be 
significantly speeded up on all implementations?

>     Don't you have to find out which machines emulate floating point and 
>which ones emulate decimal?  For any machine thats out there that 
>implements decimal but emulates floating point, your application will run 
>slower. 

My understanding is that most machines handle D_float and the accuracy
afforded by D_float will satifisfy 95% of our customer base.  We knew we
had to do something about packed decimal because it is emulated on the
VAXes (3000 & 6000 series) most used by our customer base.  The H_float
issue is not pivotal in our plans.

>     What was wrong with the multiple precision integer approach 
>[discussed via MAIL], with which decimal string operations would be 
>significantly speeded up on all implementations?

Quadword multiplication can produce octaword results.  The algorithms
shown to me to do quadword multiplication discarded the the high order
quadword of an octaword result, which is not acceptable.   Multiplication,
however is not what concerns me.  Quadword division is considerably
more complex.  Moreover operations with small operands can yield large
results (in terms of signicant digits -  egs. 1/3).  Further operations
with that result will lead to considerable execution time using quadword
algorithms for multiply and divide.  Another downside to the binary
scheme is the additional code that must be maintained.  Bottom line:
D_float will be faster and easier to maintain.

marty belliveau
DSM engineering

>Quadword multiplication can produce octaword results.  The algorithms
>shown to me to do quadword multiplication discarded the the high order
>quadword of an octaword result, which is not acceptable.   

     You aren't being fair.  Of course there are algorithms that will do 
the right thing.  Here's the basic idea for multiplying two octawords.
This is just the basic idea; lots of junk has been removed:

	EMUL	(RA)+, (RB),  #0,  (RD)+	; RA.LW0 * RB.LW0
	EMUL	(RA)+, (RB), (RD), (RD)+	; RA.LW1 * RB.LW0 + PREVIOUS.HI
	EMUL	(RA)+, (RB), (RD), (RD)+	; ETC.
	EMUL	(RA),  (RB)+,(RD), (RD)
	TSTL	4(RD)
	BNEQ	DV
	SUBL2	#12., RA
	SUBL2	#08., RD
	EMUL	(RA)+, (RB), (RD), (RD)+	; RA.LW0 * RB.LW1
	etc, etc, etc.

>Quadword division is considerably more complex.  Moreover operations with
>small operands can yield large results (in terms of signicant digits - 
>egs. 1/3).  Further operations with that result will lead to considerable
>execution time using quadword algorithms for multiply and divide.  Another
>downside to the binary scheme is the additional code that must be
>maintained. 

     Packed decimal is fixed point, so assuming two decimal places, 1/3 
would be represented as 33.  When you divide 1 by 3, the floating point 
number will have lots of extra precision -- the result will really be 
.33333333333...  How do you convert this to .3300000000?  

     In packed decimal, if you calculate 1/3 and add it to itself twice, 
you will get .99 (33 + 33 + 33), whereas if you do the same thing in 
floating point, you'll get .9999999999...  Won't your floating point 
results diverge from the packed decimal results after a while?  

>     You aren't being fair.  Of course there are algorithms that will do 
>the right thing.  Here's the basic idea for multiplying two octawords.
>This is just the basic idea; lots of junk has been removed:

I know that algorithms DO exist to do quadword multiplication that would
suit our needs.  However, D_float also suits our needs and is faster 
and easier to maintain.

>     Packed decimal is fixed point, so assuming two decimal places, 1/3 
>would be represented as 33.  When you divide 1 by 3, the floating point 
>number will have lots of extra precision -- the result will really be 
>.33333333333...  How do you convert this to .3300000000?  

Previous versions of VAX DSM normalized the dividend to be as large as
possible with respect to the divisor to yield more digits of accuracy.

marty belliveau
DSM engineering group

    	I have said this elsewhere, but this whole thing seems to be
    diverging from the original VAX philosophy. The original architecture
    was "what does the software need".
    
    	Then they produced the VAX-11/780 which happened to implement some
    instructions faster than others (inevitably, and constrained by the
    hardware technology available at  the time).
    
    	The software after that was written to run fast on a VAX-11/780.
    The hardware later was designed to run fastest the instructions most
    commonly used by the high level languages.
    
    	Everything got hooked to 1977 hardware technology.
    
    	Maybe the compiler writers should start talking to the hardware
    engineers again, and find out if the instructions they would really
    like to use can be made to run fast - after 12 years it is possible
    that things have changed.
    
    	And then there is RISC..........