req. code for convert float to ascii

[Karlos]

@Bruce Abbot

Devpac does. My disassembler now (as of this morning) produces the correct hex format for it.

I need to check the documentation of assemblers I am not familiar with to find out if they support hex fp and what format they need.

It seems like the sort of thing that should probably be a CLI parameter for the disassembler. Or maybe you could have custom named profile files that are loaded based on a target compatibility option, that set this and any other stuff you want for a specific assembler.

Damn, you reminded me how much I disliked actually implementing the assembler for MC64K and it is terrible (basic AF, incomplete feature set, bugs galore, etc.)

[Bruce Abbott]

So I installed the latest vasmm68k_mot_aos68000, and fed my fpu test code into it.

Source code:

 OPT P=68881

  output ram:testfp

  section 1,code

main:
  fmove.s  #9.9999999999999999999,fp0
  fmove.d  #9.9999999999999999999,fp1
  fmove.x  #9.9999999999999999999,fp3

  fmove.s  #1e1,fp6
  fmove.s  #1e10,fp5

  fmove.d  #1e1,fp2
  fmove.d  #1e10,fp5
  fmove.d  #1e100,fp6
  fmove.d  #1e200,fp6
  fmove.d  #1e300,fp7

  fmove.x  #1e1,fp4
  fmove.x  #1e10,fp5
  fmove.x  #1e100,fp6
  fmove.x  #1e200,fp6
  fmove.x  #1e300,fp7
  rts

First problem was that vasm 'optimized' the code to fit in the smallest possible data size, so '.x' became '.s' or '.d'. To fix that I used the '-devpac' option, which makes vasm fully compatible with Devpac (which does not optimize by default).

Now for the interesting part, disassembly of code produced by vasm...

   fmove.s #$411fffff,fp0
   fmove.d #$4023ffffffffffff,fp1
   fmove.x #$400200009ffffffffffff800,fp3
   fmove.s #$41200000,fp6
   fmove.s #$501502f9,fp5
   fmove.d #$4024000000000000,fp2
   fmove.d #$4202a05f20000000,fp5
   fmove.d #$54b249ad2594c379,fp6
   fmove.d #$6974e718d7d76251,fp6
   fmove.d #$7e37e43c8800758c,fp7
   fmove.x #$40020000a000000000000000,fp4
   fmove.x #$402000009502f90000000000,fp5
   fmove.x #$414b0000924d692ca61bc800,fp6
   fmove.x #$42970000a738c6bebb128800,fp6
   fmove.x #$43e30000bf21e44003ac6000,fp7

...vs Devpac.

   fmove.s #$411fffff,fp0
   fmove.d #$4023ffffffffffff,fp1
   fmove.x #$400200009ffffffffffff800,fp3
   fmove.s #$41200000,fp6
   fmove.s #$501502f9,fp5
   fmove.d #$4024000000000000,fp2
   fmove.d #$4202a05f20000000,fp5
   fmove.d #$54b249ad2594c37c,fp6
   fmove.d #$6974e718d7d7625a,fp6
   fmove.d #$7e37e43c8800759b,fp7
   fmove.x #$40020000a000000000000000,fp4
   fmove.x #$402000009502f90000000000,fp5
   fmove.x #$414b0000924d692ca61be000,fp6
   fmove.x #$42970000a738c6bebb12d000,fp6
   fmove.x #$43e30000bf21e44003acd800,fp7

We see that 'large' numbers come out quite different.

However the good news is that in -devpac mode vasm supports the same 96 bit hex format, so it can produce an exact representation of disassembled code.

[paraj]

Looks like they're both only using double precision for the decimal constants, and vasm isn't doing a great job here (I know it just relies on strtold from the C library it was compiled again).

I think the closest extended precision number to 1e100 is $414b924d692ca61be758 (devpac is OK here, but truncating, not sure what vasm is up to).

Determined with a lazy python script:

def decode(n): #Only handles normal numbers
    s=n>>79 # Sign
    e=((n>>64)&0x7fff)-16383 # Exponent
    m=n&((1<<64)-1) # Mantissa
    shift = e-63
    if shift < 0:
        r = m*2**(e-63)
    else:
        r = m<<shift
    if s < 0:
        r = -r
    return r

x = 0x414b924d692ca61bc800

best=-1
target=10**100
bestdist=target
for i in range(0x8000):
    n = decode(x+i)
    dist = abs(target-n)
    if dist<bestdist:
        best=x+i
        bestdist=dist

print("$%x"%best)

[phx]

Originally Posted by Bruce Abbott

We see that 'large' numbers come out quite different.

Yes, vasm uses double precision to read floating point constants (

double

in C), so some precision is lost for the 80-bit format.

I may improve that at some point, but I didn't feel like writing my own portable high precision floating point parser. And if you really need exact floating point constants you should write them in hexadecimal anyway, as a portable assembler can always have deviations in the least significant bits, depending on the host environment it is running on.

[paraj]

Originally Posted by phx

Yes, vasm uses double precision to read floating point constants (

double

in C), so some precision is lost for the 80-bit format.

I may improve that at some point, but I didn't feel like writing my own portable high precision floating point parser. And if you really need exact floating point constants you should write them in hexadecimal anyway, as a portable assembler can always have deviations in the least significant bits, depending on the host environment it is running on.

The numbers for the double values also seem to be off by a few bits. Note that I'm not complaining, but maybe the strto(l)d functions could be improved in the library used when compiling vasm for 68k. If that's vbcc, that would likely improve other programs, right?

[Thomas Richter]

Originally Posted by paraj

The numbers for the double values also seem to be off by a few bits. Note that I'm not complaining, but maybe the strto(l)d functions could be improved in the library used when compiling vasm for 68k. If that's vbcc, that would likely improve other programs, right?

The trouble is that implementing a precise "strtod" function requires more than double precision internally, which means that if you want to do it portable, you need to implement higher-precision (e.g. extended precision) floating point primitives manually. Native C does not usually provide an "extended precision" data type (C99 has long double, but this may or may not be different from double). That is already complicated enough in assembler, but making this portable in C is even more trouble.

In assembler, it requires 64-bit shifts and bit manipulations. All of that is possible in C, but it is a lot more complicated there as C is ill-prepared for such low-level bit juggling. Modern C compilers can still generate excellent code by recognizing such primitives, but it is still a lot of work to write such C code in first place.

[Thomas Richter]

Historical remark: Aztec C also implemented its double to string and string to double implementation in C, using double with the mathieeedoubbas.library. Of course, these functions were all but precise. They were rather sub-standard.

[Thorham]

The Cephes software floating point library supports large floats (up to 336 bit) including conversion functions and is written in C: https://netlib.org/cephes/

[phx]

Thanks for that link! Indeed, the Cephes library (did they lose an 'u' there?) looks like a pretty good approach in portable ISO-C, without any GNU extensions. Compiling and linking ieee.c, econst.c and mtherr.c from 128bit.tgz would give me all 128-bit float arithmetic I need, including asctoe113() for converting an ASCII string into 128-bit float format. This should provide sufficient precision to convert it into any other IEEE format.

MIT license seems nice. Will definitely look into it!

[phx]

Originally Posted by Bruce Abbott

We see that 'large' numbers come out quite different.

I had a look at the deviations again, and took

1e100

as an example, which is:

Devpac: 54b249ad2594c37c
vasm: 54b249ad2594c379
Cephes: 54b249ad2594c37d

Other system environments seem to indicate that the Cephes result is the correct one. Example from NetBSD/amd64 (little endian words are swapped):

frank@nerthus cat x.c
#include <stdio.h>
#include <stdlib.h>

double x=1e100,y;

int main()
{
  y=strtod("1e100",0);
  printf("%X %X\n",((int*)&x)[0],((int*)&x)[1]);
  printf("%X %X\n",((int*)&y)[0],((int*)&y)[1]);
}
frank@nerthus gcc x.c
frank@nerthus ./a.out
2594C37D 54B249AD
2594C37D 54B249AD

Now it's getting interesting. Cross-compiling with vbcc on the same server for OS3/68k and emulating with VAmOS also shows the correct result for strtod(), no matter if internal soft-float or mathieee libraries:

frank@nerthus vc +aos68k x.c -lmieee
frank@nerthus vamos -S -H disable -m 4096 -- ./a.out
54B249AD 2594C380
54B249AD 2594C37D
frank@nerthus vc +aos68k x.c -lmsoft
frank@nerthus vamos -S -H disable -m 4096 -- ./a.out
54B249AD 2594C380
54B249AD 2594C37D

Same when cross-compiled under MorphOS and using its emulator (also the PPC-version for comparison):

Ram Disk:> vc +aos68k x.c -lmieee
Ram Disk:> a.out
54B249AD 2594C380
54B249AD 2594C37D
Ram Disk:> vc +morphos x.c -lm
Ram Disk:> a.out
54B249AD 2594C380
54B249AD 2594C37D

But on my A3000/060 with AmigaOS 3.5 there is a similar deviation as Bruce has seen (although, with mathieee-libraries only):

7.Ram Disk:> vc +aos68k x.c -lmieee
7.Ram Disk:> a.out
54B249AD 2594C380
54B249AD 2594C37A
7.Ram Disk:> vc +aos68k x.c -lmsoft
7.Ram Disk:> a.out
54B249AD 2594C380
54B249AD 2594C37D

So I would conclude there is a problem in the AmigaOS mathieee libraries and the vclib strtod() is fine.

[Thomas Richter]

It depends on what you describe as "problem". Remember, up to Os 3.1.4, the convention for the math libraries was "round to zero", and in 3.2, it is "round to nearest". The results you provided show a deviation of 1ulp, which is readily explained by exactly that rounding mode difference.

[phx]

Makes sense. Thanks for the explanation!