Oh, and we always use the function form (with parentheses rather than just a prefix keyword). So it is UINT8(0x44). This can be extended to your form if it is really UINT8 const-uint8-expr since () will just function as parentheses.
Tim -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Tuesday, June 14, 2016 4:50 PM To: Tim Lewis <tim.le...@insyde.com>; Zhu, Yonghong <yonghong....@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC files Tim, Good suggestions. I like L'' for single a multi-character UCS16 characters without a null terminator. I prefer "" and L"" to always have a null terminator. The GUID() syntax makes sense support both registry format and struct style GUIDs. The FDF spec also support GUID C names to define some GUID values. Since GUID values are always 128-bits, it only makes sense to allow this syntax for VOID* PCDs. The proposal here covers setting values for all PCD data types. Not just VOID*. I want to make sure the parsing is unambiguous and minimize the addition of new keywords. I think we can get by with only one new keyword of GUID(). Though even this one new keyword may not be required since all 3 GUID styles can be distinguished from all other value formats. Here is a revised proposal and example PCD values for various PCD data types: ============================================================================= I would like to propose more flexible value formats for PCDs in DEC/INF/DSC/FDF files and --pcd command line option. This would include the following: * ASCII character values using single quotes(e.g. 'A'). * ASCII multi-character values using single quotes(e.g. 'ABCD'). * UCS16 character values using L and single quotes(e.g. L'A'). * UCS16 multi-Character values using L and single quotes(e.g. L 'ABCD'). * Able to use TRUE/FALSE for UINT8/16/32/64 values * Able to use TRUE/FALSE in VOID* byte array * Able to use decimal values in VOID* byte array * Able to use ASCII single quote character values in VOID* byte arrays * Able to use byte arrays, ASCII string, Unicode String, ASCII multi-character strings, UCS16 multi-character strings for UINT8/16/32/64 values as long as they fit in the target type. * Able to assign GUID values to a VOID* PCD using a GUID() operator that supports Registry format GUIDs, C struct style GUIDs, and GUID C names. Some examples of this additional flexibility are: BOOLEAN TRUE BOOLEAN FALSE BOOLEAN 0 BOOLEAN 1 BOOLEAN {0} BOOLEAN {1} UINT8 TRUE UINT8 FALSE UINT8 0x12 UINT8 12 UINT8 'A' UINT8 {TRUE} UINT8 {0x12} UINT8 {'A'} UINT16 TRUE UINT16 0x1234 UINT16 1234 UINT16 'AB' UINT16 "A" UINT16 L'A' UINT16 {0x34, TRUE} UINT16 {27, FALSE} UINT16 {'A', 'B'} UINT32 FALSE UINT32 0x12345678 UINT32 12345678 UINT32 "ABC" UINT32 L"A" UINT32 'ABCD' UINT32 L'AB' UINT32 {0x12, 27, TRUE, 'A'} UINT64 FALSE UINT64 0x1234567812345678 UINT64 1234567812345678 UINT64 "ABCDEFG" UINT64 L"ABC" UINT64 'ABCDEFGH' UINT64 L'ABCD' UINT64 {0x12, 27, TRUE, FALSE, 'A', 'B', 'C', 'D'} VOID* {0x1, 0x2, 0x3} VOID* {10, 11, 12, 13, 14} VOID* {'X', 'Y', 'Z'} VOID* {TRUE, FALSE, FALSE, TRUE} VOID* {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE} VOID* GUID(11E13869-1896-4A07-8B21-D8B23DD2A2B4) VOID* GUID({ 0x11e13869, 0x1896, 0x4a07, { 0x8b, 0x21, 0xd8, 0xb2, 0x3d, 0xd2, 0xa2, 0xb4 } }) VOID* GUID(gEfiBlockIoProtocolGuid) Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tim Lewis > Sent: Tuesday, June 14, 2016 4:14 PM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Zhu, Yonghong > <yonghong....@intel.com>; edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in > DEC/DSC files > > Mike -- > > We have traditionally used a preprocessor to convert the following into byte > arrays: > > UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), > GUID(struct-style {} or registry style "xxxxxx-yyy..."), "" (ASCII > string no-nullterminator), L"" (UCS16 string no null-terminator), '' > (ASCII character), L'' (UCS16 character) and > DevicePath() > > Tim > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Kinney, Michael D > Sent: Tuesday, June 14, 2016 3:58 PM > To: Zhu, Yonghong <yonghong....@intel.com>; edk2-devel@lists.01.org; > Kinney, Michael D <michael.d.kin...@intel.com> > Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in > DEC/DSC files > > Zhu Yonghong, > > This proposal also applies to the optional default values in source > INF files and PCD value assignments in FDF files. We should also > extend the syntax for the --pcd command line option to the build > command to support this extended syntax. So the specs impacted by this > proposal are DEC/INF/DSC/FDF/Build. > > Can you please provide a pointer to the spec that says C format GUIDs > are supported for setting the value of a VOID* PCD? I see several > places where it states that only {} byte arrays are allowed. > > Thanks, > > Mike > > > -----Original Message----- > > From: Zhu, Yonghong > > Sent: Monday, June 13, 2016 11:27 PM > > To: Kinney, Michael D <michael.d.kin...@intel.com>; > > edk2-devel@lists.01.org; Kinney, Michael D > > <michael.d.kin...@intel.com> > > Cc: Zhu, Yonghong <yonghong....@intel.com> > > Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC > > files > > > > Hi Mike, > > > > Sorry for the delay response. I have some comment: > > 1. Is this proposal only for DEC and DSC file ? Do we need cover the > > Pcd value in the INF file and FDF file ? > > 2. From build spec, it require build tools support C format GUIDs as > > Void * PCD value, current this feature is not implemented. So > > whether this new proposal need to support the C format GUIDs as Void * PCD > > value ? > > > > Best Regards, > > Zhu Yonghong > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Kinney, Michael D > > Sent: Thursday, May 19, 2016 3:22 AM > > To: edk2-devel@lists.01.org; Kinney, Michael D > > <michael.d.kin...@intel.com> > > Subject: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC > > files > > > > Hello, > > > > Today, the DEC/DSC specifications limit the PCD value formats to the > > following: > > > > BOOLEAN TRUE or FALSE > > UINT8 8-bit decimal or hexadecimal value > > UINT16 16-bit decimal or hexadecimal value > > UINT32 32-bit decimal or hexadecimal value > > UINT64 64-bit decimal or hexadecimal value > > VOID* ASCII string(e.g. "Hello") > > VOID* Unicode string(e.g. L"Hello") > > VOID* Array of hexadecimal byte values(e.g. {0x01, 0x02}) > > > > I would like to propose more flexible value formats for PCDs. > > In DEC and DSC files. This would include the following: > > > > * Character values using single quotes(e.g. 'A'). > > * Multi-Character values using single quotes(e.g. 'ABCD'). > > * Able to use TRUE/FALSE for UINT8/16/32/64 values > > * Able to use TRUE/FALSE in VOID* byte array > > * Able to use decimal values in VOID* byte array > > * Able to use single quote character values in VOID* byte arrays > > * Able to use ASCII string, Unicode String, Multi-Character > > strings for UINT8/16/32/64 values as long as they fit in the > > target type. > > > > Some examples of this additional flexibility are: > > > > UINT8 TRUE > > UINT8 FALSE > > UINT8 0x12 > > UINT8 12 > > UINT8 'A' > > UINT16 TRUE > > UINT16 0x1234 > > UINT16 1234 > > UINT16 'AB' > > UINT16 "A" > > UINT32 0x12345678 > > UINT32 12345678 > > UINT32 "ABC" > > UINT32 L"A" > > UINT32 'ABCD' > > UINT64 0x1234567812345678 > > UINT64 1234567812345678 > > UINT64 "ABCDEFG" > > UINT64 L"ABC" > > UINT64 'ABCDEFGH' > > VOID* {0x1, 0x2, 0x3} > > VOID* {10, 11, 12, 13, 14} > > VOID* {'X', 'Y', 'Z'} > > VOID* {TRUE, FALSE, FALSE, TRUE} > > VOID* {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE} > > > > Here is a python function that can parse these formats and return an > > python integer value that does not have any size limits. Based on > > the data type, the size can be checked to see the value return fits > > in the target type. All strings and byte arrays are reversed for > > little-endian byte > ordering. > > > > NOTE: Need to add explicit null-terminator for ASCII/Unicode > > strings. Multi-character constants are not null-terminated. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Michael Kinney <michael.d.kin...@intel.com> > > > > def ParseValue (Value): > > if type(Value) == type(0): > > return Value > > if type(Value) <> type(''): > > raise ValueError > > Value = Value.strip() > > if Value.startswith('L"') and Value.endswith('"'): > > # Unicode String > > List = list(Value[2:-1]) > > List.reverse() > > Value = 0 > > for Char in List: > > Value = (Value << 16) | ord(Char) > > return Value > > if Value[0] == '"' and Value[-1] == '"': > > # ASCII String > > List = list(Value[1:-1]) > > List.reverse() > > Value = 0 > > for Char in List: > > Value = (Value << 8) | ord(Char) > > return Value > > if Value[0] == "'" and Value[-1] == "'": > > # Character constant > > List = list(Value[1:-1]) > > List.reverse() > > Value = 0 > > for Char in List: > > Value = (Value << 8) | ord(Char) > > return Value > > if Value[0] == '{' and Value[-1] == '}': > > # Byte array > > Value = Value[1:-1] > > List = [Item.strip() for Item in Value.split(',')] > > List.reverse() > > Value = 0 > > for Item in List: > > ItemValue = ParseValue(Item) > > if ItemValue > 255: > > raise ValueError > > Value = (Value << 8) | ItemValue > > return Value > > if Value.lower().startswith('0x'): > > return int(Value, 16) > > if Value[0].isdigit(): > > return int(Value, 10) > > if Value.lower() == 'true': > > return 1 > > if Value.lower() == 'false': > > return 0 > > raise ValueError > > > > Best regards, > > > > Mike > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
