-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PFPO is never setting the CC (and is never setting GR1 either) #527
Comments
Let me take a look at it. Give me a couple of days. |
Thanks, Steve! (@srorso) MUCH appreciated. You might want to do another git pull before you start. I just made some cosmetic tweaks to Bob's code (just comments) to make it a little easier(?) to understand his code. (Trust me, they're very minor and 100% cosmetic) I'm going to continue looking at it myself in the hope that it will eventually sink in. If I have any "Ah-HA!" moments I'll be sure to run them by you for confirmation before doing anything. (The endianness issue was easy compared to this one! His code is weird!) |
I swore on my wife's ashes that I would not drop acid anymore. And here I am doing floating point and reaching for Windowpane. Sorry dear. OK. Fish, your comment additions are helpful and on point. The code in More comments in the code would greatly improve its maintainability, especially by programmers more resolute in their avoidance of certain substances. I see where condition code is set in And I see that the Here is what should be done right now:
But wait, that can't be it, you think...or say. You'd be right. But the present coding allows no more than the above. Here are things that
This one is pretty easy. To correct, the code at lines 2304-2311 should be replace the code at 2431-2433.
Adding this involves changes to a modest number of functions. Non-trivial, more research would be needed to provide details.
Scaled results are a bear. Scale factors are specific to target format and precision. A formula can be found on p.9-39 of PoO -13, but that's useless. Better to get the target- and precision-specific factors from PoO Figure 19-9 part 2 on p. 19-9, and Figure 20-6 on pp.20-12 to 20-14, for BFP and DFP, respectively. BFP generates scaled results when trappable IEEE overflow or underflow occur. Adding this to
Testing
Test results generated for each target
First term: number of target precisions. Second term: number and source of rounding modes, So one HFP source in one precision can, for thorough testing, generate 261 test cases. A DFP source in one precision can create 189 results, and a BFP source in one precision can generate 216 results. Just converting the value "+1.0" from nine source formats and precisions to all available target precisions will generate:
For a grand total of 1,998 results. Call it 2K. Not bad for one number, and not a very interesting one. But runtest is not up to the task. I've been working on this but nowhere near something that is better than runtest for large-scale result tests. |
That's what I was thinking of doing too. But of course looking at his code,
Another thing I was also thinking of doing. But once again, always setting it to zero seems wrong. According to the manual, it's, I think, supposed to be the "Signed Scaling Exponent" value (whatever the heck that is), which I'm presuming just so happens, in most circumstances, to usually be zero. Nevertheless, since it seems you're just as baffled by Bob's code as I am, I will make the suggested changes. It's probably the best we can hope for at the moment. We'll just have to document in the Release Notes that the (I sure wish Bob (@rwoodpd) was more active as a developer and would jump in and make the needed changes to his own code for us! Bob? Where are you buddy?)
Well.... close, but not quite. I understand what you're getting at though, so you're right that this fix is pretty easy. But it's not quite as easy as you make it out to be. The existing code at 2313-2318 that's returning immediately when the test bit is set, needs to have it's own mini-switch statement that simply sets Otherwise we would have to add an In any case another easy fix I will certainly take care of. Thanks.
I saw those too, but unfortunately they're mostly complete gibberish to me.
At least you have a IEEE-854 hat! I don't. And it wouldn't do any good giving one to me either: it wouldn't fit. My head's too small.
Duh! An understatement if I ever heard one.
Another understatement.
Anything that you (or anyone else for that matter!) can do for us, Steve, would be greatly appreciated! ANYTHING! In the mean time I want you to know how very much I (indeed all of us!) appreciate your feedback on this issue, Steve. You're a good man. I'll go ahead and make the few quick changes you suggested for now, and keep scratching my head over Bob's code. Maybe given enough time I actually might start to understand some of it. Or at least hopefully enough to maybe figure out where cc=1 needs to be returned and/or where the Take care, Steve, and thanks for the help. Stay away from the acid. |
The switch ...I've been wrong before, will be again.. |
Again, close but no cigar.
Where are you seeing this? The default branch in the previous two switches only sets And what do you mean by "each of the three Are you tripping again? I thought you promised to stay away from that acid shit.
Nope. The only way to do it that I can see is by adding another There are a few other tweaks I want to make related to the handling of the FPC flags defined in I'll post my final patch here for peer review before committing it just in case my own mind is misbehaving as badly as yours apparently is. (Which wouldn't be the first time for ME either!) |
Committed 2e984f9:
I will continue studying Bob's code as time permits to hopefully ONE DAY figure out where CC=1 and GR1 Return Code value needs to be properly set. But don't hold your breath. I consider this to be low priority right now, as there are other more important things I'm working on. I encourage ALL DEVELOPERS (as well as any users out there skilled at Floating-Point!) to PLEASE take a crack at trying to help us out! (Please?) Thanks. Will leave GitHub Issue status as "OnGoing"... |
The title says it all:
The
PFPO
instruction appears to never be setting the Condition Code, as well as appears to never be placing any type of Return Code value into General Register 1 either.Bob's code is very hard to understand and follow (at least for me anyway) due not only to his coding style, but also due to the inherent complexity of Floating-Point concepts in general.
My mind just has a hard time wrapping itself around floating-point in general, but has an especially hard time following Bob's code too.
I could use some help on this one folks!
:-(
The text was updated successfully, but these errors were encountered: