From: tkoenig@netcologne.de   
      
   Kent Dickey  schrieb:   
      
   > For FP, Arm32 has an 8-bit immediate turned into an FP number as follows:   
   >   
   > sign = imm8<7>;   
   > exp = NOT(imm8<6>):Replicate(imm8<6>,E-3):imm8<5:4>;   
   > frac = imm8<3:0>:Zeros(F-4);   
   > result = sign : exp : frac;   
   >   
   > For Float, exp[7:0] can be 0x80-0x83 or 0x7c-0x7f, which is 2^1 through 2^4   
   > and 2^-3 through 2^0.  And the mantissa upper 4 bits are from the immediate   
   > field.  Note that 0.0 is not encodeable, and I'm going to assume you   
   > don't need it either.   
      
   Looking at the statistics upthhead, 0.0 is the most common floating   
   point constant for My 66000 code.   
      
   > For your FP, the sign comes from elsewhere, so you have 5 bits for the   
   > FP number.  I suggest you use the Arm32 encoding for the exponent (using   
   > 3 bits), and then set the upper 2 bits of the mantissa from the remaining   
   > two immediate bits.   
   >   
   > This encodes integers from 1.0 through 8.0, and can also encode 10.0, 12.0,   
   > 14.0, 16.0, 20.0, 24.0, and 28.0.  And it can do 0.5, 1.5, 2.5, 3.5.   
   > And it can encode 0.125 and 0.25.   
   >   
   > This encoding makes a lot of sense from ease of decode.  However, it   
   > would be nice to be able to encode 100.0, 1000.0 and .1, .01 and .001, each   
   > of which is likely to be more useful than 12.0 or 3.5.   
      
   This is really hard to quantify, and going by gut feeling is likely to   
   give wrong results.  Do you have any statistics, done on more software   
   packages than what I have done, on the ditribution of floating point   
   constants?   
      
   > From a compiler standpoint, having arbitrary constants is perfectly fine,   
   > it can just look up if it's available.  So you can make 1000.0 and .001   
   > and PI and lg2(e) and ln(2), and whatever available, if you want.   
   > GCC looks up Arm64 integer 13-bit immediates in a hashtable--the encoding   
   > is almost a one-way function, so it's just faster to look it up rather than   
   > try to figure out if 0xaaaaaaaa is encodeable out by inspecting the value.   
   > So something similar could be done for FP constants.  Since the values will   
   > be fixed, a perfect hash can be created ensuring it's a fast lookup.   
      
   Sure, it can be done, but I would like to do it on the basis of hard(er)   
   data.   
      
   --   
   This USENET posting was made without artificial intelligence,   
   artificial impertinence, artificial arrogance, artificial stupidity,   
   artificial flavorings or artificial colorants.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)