Sometimes our pseudocode uses strings as enumeration values. This is bad for both Python and especially C. Example: * fcfids FRT,FRB (Rc=0) * fcfids. FRT,FRB (Rc=1) Pseudo-code: FRT <- INT2FP(FRB, 'sint2single') The second argument is a string, which means that we would use strcmp in C code which just performs an int->fp conversion. Whilst this is not a blocker, I recommend to reconsider these. We could either use some special token (literally matching 'sint2single' along with the quotes), or, better, fix the pseudocode to use an integer literal.
we don't have any choice: it's an official part of the spec. recommendation is to convert to a #define "sint2single" => #define SINT2SINGLE 1 unfortunate but we cannot tell the OPF "hey guys get rid of strings" when the pseudocode was never intended to be executable
fcfids doesn't have the pseudocode. It just happens that "A.3 Floating-Point Convert from Integer Model" specifies precision as string, but does it in the conversion __internals__. if Floating Convert From Integer Doubleword then do tgt_precision “double-precision” sign (FRB)0 exp 63 frac0:63 (FRB) end ...and therefore in the body of this "if" we can check anything we want. Including integral constant. That is, you can pass anything to INT2FP, because the standard lacks the mere idea you used INT2FP.
This includes the fact that the standard lacks any of sint2double, sint2single, etc. These are our invention, even A.3 pronounces these differently.
FTR, I'm referring to 3.1B.
(In reply to Dmitry Selyutin from comment #4) > FTR, I'm referring to 3.1B. please don't. refer to where the pseudocode was extracted: 5 6 <!-- Power ISA Book I Version 3.0B Section A.3 page 782 --> 7 https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isafunctions/fpfromint.mdwn;hb=HEAD it is *not* getting changed. no amount of justification for "it should be" or "this is stupid" will override the fact that these functions are directly out of the spec and they are just not going to be changed: that, sorry to have to say it, is simply the end of the matter. if we ourselves had invented this pseudocode it would be a different matter entirely... (but only when the chnges could be scheduled and evaluated for cost and impact) i come across this a lot, someone in a Corporation makes a dumb decision, everyone has to live with it due to compatibility reasons.
Luke. I cannot help you if you don't read what I write. 1. Open the specification. 2. Find INT2FP there. 3. Find any of 'sint2double', 'sint2single', 'uint2double', 'uint2single'.
Don't even proceed with this bug state until you show me the exact pages in 3.1B which contain this EXACT words I mentioned. If these EXACT words are absent -- this code is not part of the spec and is just your interpretation which can be done without the string.
(In reply to Dmitry Selyutin from comment #7) > Don't even proceed with this bug state until you show me the exact pages in > 3.1B which contain this EXACT words I mentioned. there is not time, and we are not using 3.1B. again, third time, so sorry to have to say it: no change is being made to pseudocode, Dmitry. jacob has provided some solutions including code that morphs strings into constants. we do not have time to debate this, and certainly do not have time or budget to make (and then test) any pseudocode changes (which are mot houng to happen). so sorry. please leave this bug closed and closed as invalid
The situation is completely the same in the version 3.0B. This is an issue. It's you who introduced the pseudocode not found in the spec.
Luke, it's time to finally check the specification and prove I'm wrong. There's no INT2FP function, the spec talks in generic terms "if Floating Convert From Integer Doubleword then do". There's no reason to substitute this if with string. There's no reason for this debate other that unwillingness to admit your faults.
This is not going to be closed until you admit you was wrong. This can be closed only as "deferred", otherwise it creates a false impression this is not a bug. Meanwhile it is.
since there's only one string for now, just translate it to an integer and put a FIXME in the translation code, or something similar. we can figure the rest out later as part of another bug. I'm marking this bug deferred, Luke and Dimitry, please just drop it for now. you can go through why you think it is or isn't a bug later, when we come back to it. note for later when we come back to it: when we add function support, strings are much more commonly used and are part of the pseudocode in the specification (e.g. Appendix A.1 where it uses the string "+ zero" as the value assigned to FPSCR.FPRF), so, then, supporting one more string is much less additional work.
Thanks Jacob, such wording I can totally accept.