Eric -- The UEFI specification says that "Data conversion is not implicit. Explicit data conversion can be performed using the EFI_IFR_TO_STRING, EFI_IFR_TO_UINT, and EFI_IFR_TO_BOOLEAN operators." (29.2.5.7.4) The VFR compiler in this case is generating code that would not work on a conformant Form Browser, because the result of == is BOOLEAN TRUE (not 1), and | does not take type BOOLEAN for either operand. The spec says that if either type does not evaluate as an Integer, the result should be "Undefined"
Suppressif takes a result of BOOLEAN TRUE (not integer 0 or non-zero). The result of suppressif with a result of Undefined is not mentioned in the specification. Tim -----Original Message----- From: Dong, Eric [mailto:eric.d...@intel.com] Sent: Friday, August 29, 2014 11:16 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Bitwise OR operator problems I check the current implementation of browser and vfrcompile, detail shows below: Below IFR data generated from the vfr file: suppressif 8|8 == 0x8; >000001AA: 0A 82 >000001AC: 45 8A 08 00 00 00 00 00 00 00 >000001B6: 45 0A 08 00 00 00 00 00 00 00 >000001C0: 45 0A 08 00 00 00 00 00 00 00 >000001CA: 2F 02 >000001CC: 36 02 >000001CE: 29 02 checkbox varid = MyIfrNVData.ChooseToActivateNuclearWeaponry, >000001D0: 06 8E 29 00 2A 00 03 00 34 12 D4 00 00 03 prompt = STRING_TOKEN(0x0029), help = STRING_TOKEN(0x002A), flags = CHECKBOX_DEFAULT | CHECKBOX_DEFAULT_MFG, default = TRUE, >000001DE: 5B 06 00 00 00 01 endcheckbox; >000001E4: 29 02 endif; >000001E6: 29 02 In browser, when do the "|" operate, it save the result as an UINT64 type and the result is 0x9. When check the suppressif opcode, it found the data type is UINT64 and value is 0x9,not 0, so the checkbox is suppressed. Thanks, Eric -----Original Message----- From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Friday, August 29, 2014 7:18 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Bitwise OR operator problems So this leads to the follow on question (now that I've got the precedence straight): suppressif 8|8 == 0x8 is an illegal statement. in IFR (8 8 EFI_IFR_EQUAL 8 EFI_IFR_BITWISE_OR) since EFI_IFR_EQUAL results in a BOOLEAN, but EFI_IFR_BITWISE_OR requires an integer, and IFR is strongly typed. In Laszlo's original analysis: 8|(8 == 0x8) means 8|1 The specification says: This opcode performs the following actions: 1. Pop two expressions from the expression stack. 2. If the two expressions cannot be evaluated as unsigned integers, push Undefined. 3. Otherwise, zero-extend the unsigned integers to 64-bits. 4. Perform a bitwise-OR of the two values. 5. Push the result. There is no implicit type conversion in IFR, so in order for VfrCompile.exe to handle this expression, I would expect a EFI_IFR_TO_BOOLEAN to be generated implicitly. But in my analysis of the IFR being generated, it is not. In fact, an optimizer tool we have written catches these as errors, along with the fact that the suppressif expression is not evaluating to a bool. Tim -----Original Message----- From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, August 28, 2014 5:53 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Bitwise OR operator problems Laszlo -- You are correct. I have verified the VFR grammar which has similar priority. It is actually the behavior for integer conversion in suppressif that is confusing me, not the order of evaluation like I thought. Tim -----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, August 28, 2014 5:43 PM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Bitwise OR operator problems On 08/28/14 11:31, Laszlo Ersek wrote: > In the C language, both operator & and operator | bind > *less* strongly than operator ==. (Sorry for following up on my own email.) I found some references: http://en.wikipedia.org/wiki/Operator_precedence_in_C#Criticism_of_bitwise_and_equality_operators_precedence http://cm.bell-labs.com/cm/cs/who/dmr/chist.html See under "Neonatal C". Thanks Laszlo ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
