Re: [edk2] Bitwise OR operator problems
Tim, I agree the browser should not process BOOLEAN type as an integer, and it should push a "Undefined" to the stack when process "|" opcode. Later when process suppressif opcode, the stack popup an "Undefined" result which is not "TRUE", so I think the question nest it will not be suppressed, do you think this behavior is acceptable? Thanks, Eric -Original Message- From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Friday, August 29, 2014 11:31 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] Bitwise OR operator problems 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; >01AA: 0A 82 >01AC: 45 8A 08 00 00 00 00 00 00 00 >01B6: 45 0A 08 00 00 00 00 00 00 00 >01C0: 45 0A 08 00 00 00 00 00 00 00 >01CA: 2F 02 >01CC: 36 02 >01CE: 29 02 checkbox varid = MyIfrNVData.ChooseToActivateNuclearWeaponry, >01D0: 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, >01DE: 5B 06 00 00 00 01 endcheckbox; >01E4: 29 02 endif; >01E6: 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
Re: [edk2] Bitwise OR operator problems
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; >01AA: 0A 82 >01AC: 45 8A 08 00 00 00 00 00 00 00 >01B6: 45 0A 08 00 00 00 00 00 00 00 >01C0: 45 0A 08 00 00 00 00 00 00 00 >01CA: 2F 02 >01CC: 36 02 >01CE: 29 02 checkbox varid = MyIfrNVData.ChooseToActivateNuclearWeaponry, >01D0: 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, >01DE: 5B 06 00 00 00 01 endcheckbox; >01E4: 29 02 endif; >01E6: 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 -
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; >01AA: 0A 82 >01AC: 45 8A 08 00 00 00 00 00 00 00 >01B6: 45 0A 08 00 00 00 00 00 00 00 >01C0: 45 0A 08 00 00 00 00 00 00 00 >01CA: 2F 02 >01CC: 36 02 >01CE: 29 02 checkbox varid = MyIfrNVData.ChooseToActivateNuclearWeaponry, >01D0: 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, >01DE: 5B 06 00 00 00 01 endcheckbox; >01E4: 29 02 endif; >01E6: 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
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
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
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
Re: [edk2] Bitwise OR operator problems
On 08/28/14 07:18, Tim Lewis wrote: > It appears that this should prevent the display of the text statement. > However, to my surprise, it works on NT32. Per operator precedence, it > should be 8|8 is 8, and 8 == 8 is TRUE. > > > > suppressif 8|8 == 0x8; > > text > > help = STRING_TOKEN(STR_BITWISE_OR_HELP), > > text = STRING_TOKEN(STR_BITWISE_OR_PROMPT); > > endif; > > > > The equivalent 8&8 == 0x8 has no problem. I must disagree. In the C language, both operator & and operator | bind *less* strongly than operator ==. In 6.5 Expressions p3 it says The grouping of operators and operands is indicated by the syntax. (footnote 74). [...] Footnote 74 says The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. [...] And 6.5.9 Equality operators Syntax 1 equality-expression: relational-expression equality-expression == relational-expression equality-expression != relational-expression [...] 6.5.10 Bitwise AND operator Syntax 1 AND-expression: equality-expression AND-expression & equality-expression Hence "equality-expression" is a stronger binding than "AND-expression". Then, 6.5.11 Bitwise exclusive OR operator Syntax 1 exclusive-OR-expression: AND-expression exclusive-OR-expression ^ AND-expression [...] 6.5.12 Bitwise inclusive OR operator Syntax 1 inclusive-OR-expression: exclusive-OR-expression inclusive-OR-expression | exclusive-OR-expression Hence "equality-expression" is a stronger binding than "inclusive-OR-expression", transitively, via "AND-expression" and "exclusive-OR-expression". So, at least in C (not sure about the VFR language), 8|8 == 0x8 means 8|(8 == 0x8) means 8|1 means 9 This compares unequal to zero, so in a "truth" context, it means "true". As I understand, you don't see that (ie. even though the binding is different from what you assumed, the end result should coincide with your expectation, but it doesn't happen.) Maybe there's a bug in the form engine that uses "== 1" rather than "!= 0" for truth checks. Then, 8&8 == 0x8 means 8&(8 == 0x8) means 8&1 means 0 which is "false" (independently of whether the form engine otherwise uses the correct "!= 0" form, or the incorrect "== 1" form). 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
[edk2] Bitwise OR operator problems
It appears that this should prevent the display of the text statement. However, to my surprise, it works on NT32. Per operator precedence, it should be 8|8 is 8, and 8 == 8 is TRUE. suppressif 8|8 == 0x8; text help = STRING_TOKEN(STR_BITWISE_OR_HELP), text = STRING_TOKEN(STR_BITWISE_OR_PROMPT); endif; The equivalent 8&8 == 0x8 has no problem. -- 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