View Single Post
Old 31 December 2022, 20:18   #39
Bruce Abbott
Registered User
 
Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,590
Quote:
Originally Posted by Thomas Richter View Post
I suggest trying COP as debugger. It uses the "known good" conversion from the library I quoted above.
I had COP installed on my system but didn't have a use for it until now (some day I must hook an external terminal up to my A1200 and try doing some hardcore debugging!).

According to COP the binary values for 1E200 and 1E300 are correct. This validates the assemblers' output and indicates that my conversion code is not accurate.

Quote:
Originally Posted by Karlos View Post
Provided the assembler you aim to reassemble the code with supports the hex representation of the floating point value,
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.

Quote:
Originally Posted by Kalms View Post
That sounds like you don't know where the IEEE numbers originated from, and you want to preserve IEEE => decimal => IEEE roundtrip-ability. Thus, you want choice #2. You will get roundtrip-ability, but some numbers (like 0.1) will look ugly in the disassembly (you will see 0.100000001). That is the price you have to pay to get roundtrip-ability for all IEEE numbers.
Unfortunately it doesn't, because the assembler may take that slightly different number and generate yet another different floating point number.

But that's OK. I provide the option of showing the number (or entire instruction) in hex, then show the decimal version in the comment field. The user can toggle the on-screen format at any time for better understanding of the code. To this end I am thinking of showing fewer decimal digits and rounding to it.

As Thomas says, this is just 'optics', but in this case I think it's appropriate. Most 'industry standard' code only uses double precision anyway, except perhaps for internal calculations (which is why it's so hard to find an accurate converter for extended precision).

The main purpose of my disassembler is to aid in patching 'legacy' programs for which there is no source code available. Accurate reassembly is important for this because you don't know what effect any differences might have. However there aren't many programs I am interested in that have a lot of inline floating point code. AIBB is one. It includes both 68881 and 040 optimized code. This makes it a good test subject.

Last edited by Bruce Abbott; 31 December 2022 at 20:27.
Bruce Abbott is online now  
 
Page generated in 0.04438 seconds with 11 queries