Re: [Devel] Concatenate() operator

Re: [Devel] Concatenate() operator

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]


There are a few things going on here.

1) The version of the DSDT is 1, so integers are 32 bits (as per ACPI specification). So, any integers larger than 32 bits are truncated to 32 bits. Change the version to 2, and you will get 64-bit integers.

2) Yes, the strings will be converted to integers

2) The compiler is folding both Concatenate operators to simple constants (buffers). 

3)The string-to-integer implicit conversion is in fact covered by the ACPI spec, and the strings are always treated as hex constants, as below:

19.3.5.7 Data Type Conversion Rules

From String-to-Integer conversion section from the table:

"the ASCII string is interpreted as a hexadecimal constant"
"a 0x prefix is not allowed"

There are no octal constants in all of ACPI, BTW.


I think this covers your questions.
Bob

Re: [Devel] Concatenate() operator

[Al Stone]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

On 06/13/2017 09:03 AM, Moore, Robert wrote:
> Lack of octal support appears to be an oversight. We are fixing this for the next release of ACPICA/iASL.
> 
> Thanks,
> Bob
> 
> 
>> -----Original Message-----
>> From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
>> Sent: Friday, June 2, 2017 2:37 PM
>> To: ahs3(a)redhat.com; devel(a)acpica.org
>> Subject: Re: [Devel] Concatenate() operator
>>
>>

Thanks for the follow-up!

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Re: [Devel] Concatenate() operator

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

Lack of octal support appears to be an oversight. We are fixing this for the next release of ACPICA/iASL.

Thanks,
Bob


> -----Original Message-----
> From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
> Sent: Friday, June 2, 2017 2:37 PM
> To: ahs3(a)redhat.com; devel(a)acpica.org
> Subject: Re: [Devel] Concatenate() operator
> 
> 

Re: [Devel] Concatenate() operator

[Moore, Robert]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]



> -----Original Message-----
> From: Al Stone [mailto:ahs3(a)redhat.com]
> Sent: Friday, June 2, 2017 8:59 AM
> To: Moore, Robert <robert.moore(a)intel.com>; devel(a)acpica.org
> Subject: Re: [Devel] Concatenate() operator
> 
> On 06/02/2017 08:48 AM, Moore, Robert wrote:
> >
> > There are a few things going on here.
> >
> > 1) The version of the DSDT is 1, so integers are 32 bits (as per ACPI
> specification). So, any integers larger than 32 bits are truncated to 32
> bits. Change the version to 2, and you will get 64-bit integers.
> 
> Ah.  Missed this part.  That helps some.
> 
> > 2) Yes, the strings will be converted to integers
> >
> > 2) The compiler is folding both Concatenate operators to simple
> constants (buffers).
> 
> Yup, got that part.
> 
> > 3)The string-to-integer implicit conversion is in fact covered by the
> ACPI spec, and the strings are always treated as hex constants, as
> below:
> >
> > 19.3.5.7 Data Type Conversion Rules
> >
> > From String-to-Integer conversion section from the table:
> >
> > "the ASCII string is interpreted as a hexadecimal constant"
> > "a 0x prefix is not allowed"
> >
> > There are no octal constants in all of ACPI, BTW.
> 
> Okay.  Now I see why this happens.  Thanks.
> 
> The part about octal is not correct, though.  ASL literal constants are
> allowed to be decimal, hexadecimal, or octal -- 
[Moore, Robert] 

Yes, it looks like you are right about this. We'll investigate a bit further.
Thanks,
Bob



that's what section
> 19.3.2.1 says quite explicitly.  iasl does appear to behave properly
> with 32-bit values, but it looks like 64-bit octal conversion is off a
> bit; here's a simple test case for
> that:
> 
> DefinitionBlock ("", "DSDT", 2, "xxxxx", "Many", 0x00000001) {
> 	Name (WBCD, 321)
> 	Name (WBCO, 0321)
> 	Name (WBCX, 0x0321)
> 
> 	Name (QBCD, 987654321987654321)
> 	Name (QBCO, 066646645757675011261)
> 	Name (QBCX, 0xdb4da5f7ef412b1)
> }
> 
> The QBC* values should all produce identical bytes; decimal and hex are
> correct.
> 
> > I think this covers your questions.
> > Bob
> >
> >
> 
> 
> --
> ciao,
> al
> -----------------------------------
> Al Stone
> Software Engineer
> Red Hat, Inc.
> ahs3(a)redhat.com
> -----------------------------------

Re: [Devel] Concatenate() operator

[Al Stone]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On 06/02/2017 08:48 AM, Moore, Robert wrote:
> 
> There are a few things going on here.
> 
> 1) The version of the DSDT is 1, so integers are 32 bits (as per ACPI specification). So, any integers larger than 32 bits are truncated to 32 bits. Change the version to 2, and you will get 64-bit integers.

Ah.  Missed this part.  That helps some.

> 2) Yes, the strings will be converted to integers
> 
> 2) The compiler is folding both Concatenate operators to simple constants (buffers). 

Yup, got that part.

> 3)The string-to-integer implicit conversion is in fact covered by the ACPI spec, and the strings are always treated as hex constants, as below:
> 
> 19.3.5.7 Data Type Conversion Rules
> 
> From String-to-Integer conversion section from the table:
> 
> "the ASCII string is interpreted as a hexadecimal constant"
> "a 0x prefix is not allowed"
> 
> There are no octal constants in all of ACPI, BTW.

Okay.  Now I see why this happens.  Thanks.

The part about octal is not correct, though.  ASL literal constants are allowed
to be decimal, hexadecimal, or octal -- that's what section 19.3.2.1 says quite
explicitly.  iasl does appear to behave properly with 32-bit values, but it
looks like 64-bit octal conversion is off a bit; here's a simple test case for
that:

DefinitionBlock ("", "DSDT", 2, "xxxxx", "Many", 0x00000001)
{
	Name (WBCD, 321)
	Name (WBCO, 0321)
	Name (WBCX, 0x0321)

	Name (QBCD, 987654321987654321)
	Name (QBCO, 066646645757675011261)
	Name (QBCX, 0xdb4da5f7ef412b1)
}

The QBC* values should all produce identical bytes; decimal and
hex are correct.

> I think this covers your questions.
> Bob
> 
> 


-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

[Devel] Concatenate() operator

[Al Stone]

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

I'm a little confused by what the spec is telling me and what the code is
actually doing for the Concatenate() operator.

Here's the ASL I'm working with (it's an iasl test, so it doesn't really
have to make a lot of sense):

DefinitionBlock ("", "DSDT", 1, "Intel", "Many", 0x00000001)
{
	Method (M64G, 0, NotSerialized)
        {
            Local0 = Concatenate (0x0321, "0321")
            Local0 = Concatenate (0x0321, "FE7CB391D650A284")
	    Return(Local0)
	}
}

The resulting AML looks like this (from hexdump -C):

00000000  44 53 44 54 49 00 00 00  01 21 49 6e 74 65 6c 00  |DSDTI....!Intel.|
00000010  4d 61 6e 79 00 00 00 00  01 00 00 00 49 4e 54 4c  |Many........INTL|
00000020  03 03 17 20 14 24 4d 36  34 47 00 70 11 0b 0a 08  |... .$M64G.p....|
00000030  21 03 00 00 21 03 00 00  60 70 11 0b 0a 08 21 03  |!...!...`p....!.|
00000040  00 00 91 b3 7c fe 60 a4  60                       |....|.`.`|
00000049

Bytes 0x0030-0x0038 are the first use of Concatenate():

	Concatenate (0x0321, "0321")

If I understand the spec correctly (19.6.12), since the first operand is an
Integer, the second is to be "implicitly converted if necessary (and possible)
to match" -- hence, to an Integer.  The String "0321", *if* it is assumed to be
a hex value, seems okay.

So, my first question is: is that a reasonable assumption?  I suspect the answer
is "probably" but I don't recall seeing anything in the spec that says that a
string conversion to an integer will always assume the string represents a hex
value; as someone who spends more time with C than ASL, I assumed that would be
an octal value.  And, because of section 19.3.2.1, I was surprised it was not
treated as octal, so the AML is looking wrong to me (0321 should be 0xd1)

The second usage (bytes 0x003e-0x0046 is even stranger to me:

	Local0 = Concatenate (0x0321, "FE7CB391D650A284")

If we assume the String is hex again -- though it should be "0xFE7CB391D650A284"
to be proper -- it is a valid 64-bit integer but it gets truncated to 32-bits in
the AML.

So, the second question is: why?  Since the operator is returning a Buffer or a
String, there doesn't seem to be any reason to truncate the value -- or at least
nothing I'm finding in the spec; in fact, quite the contrary.

This all leads to the third question: which one is correct -- iasl or the spec?
Or am I just missing something obvious?

Thanks.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------