Re: [Devel] Field Offset constraints

Re: [Devel] Field Offset constraints

[Moore, Robert]

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

We do in fact keep tightening up the compiler to check for semantic issues as well as syntax errors. As it stands today, we have 164 errors/warnings/remarks, as well as 13 additional errors for the Data Table compiler, and 11 errors for the preprocessor.

Do you have any additional suggestions?

Bob


From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Wednesday, April 3, 2019 11:08 AM
To: Moore, Robert <robert.moore(a)intel.com>
Cc: devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
Subject: Re: [Devel] Field Offset constraints

Hi Robert,

Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>:
2)      Disable the specific remark via the –VW option.
iasl -vw 2158 dsdt.asl   // disable remark #2158
Thank you for the pointer to that option, that's very helpful.

Independent from that, is there interest in providing language features on top of ASL (maybe in revisions to the spec if the tool is meant to remain strictly compliant) to more rigorously express constraints that can be verified at compile time?


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5829 bytes --]

Re: [Devel] Field Offset constraints

[Moore, Robert]

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

BTW, iASL does in fact have a preprocessor that supports #include and simple #defines (no full macros yet, we’d like to integrate an off-the-shelf existing macro processor).
Bob


From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Thursday, April 4, 2019 1:36 PM
To: Schmauss, Erik <erik.schmauss(a)intel.com>
Cc: Moore, Robert <robert.moore(a)intel.com>; devel(a)acpica.org
Subject: Re: [Devel] Field Offset constraints

One (simple) example would be the mapping between https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h#269 that specifies addresses in EC "RAM" space to https://review.coreboot.org/cgit/coreboot.git/tree/src/ec/google/chromeec/acpi/ec.asl#n42. Right now, there's relatively little to ensure that (let's say) "FAND" in the ASL really points to the same address as EC_ACPI_MEM_FAN_DUTY.

Later in the ASL we use Offset to make sure that the bitfield doesn't exceed the space it has (line 91), as a very weak assertion that the code is sane.
The ability to concretely specify where each of these fields is supposed to end up instead having to count would increase the confidence in the ACPI side of things.

(If things look a bit odd in the ASL: we run it through cpp to support #include and #define)


Thanks,
Patrick

Am Do., 4. Apr. 2019 um 22:12 Uhr schrieb Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>:
Hi Patrick,

I assume that you are trying to translate a specification that contains diagrams to this ASL OperationRegion. Could you send us an image of what this diagram or specification looks like? We don’t need the exact specification. I’m just curious as to what this specification looks like. Feel free to blank-out any proprietary or sensitive fields.

Thanks,

Erik

From: Patrick Georgi [mailto:pgeorgi(a)google.com<mailto:pgeorgi(a)google.com>]
Sent: Wednesday, April 3, 2019 2:52 PM
To: Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Cc: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>; devel(a)acpica.org<mailto:devel(a)acpica.org>
Subject: Re: [Devel] Field Offset constraints

Hi Erik,
thanks for the encouraging words.

As mentioned, I think it would be useful to have a mechanism to lock down where a field item ends up.
We used to use Offset() for that purpose to make sure that at least we're not putting more into a space than fits into it (because Offset() won't move backward), but something more comprehensive (that can also identify underflow for example) would be nice.

The (optional) syntax I proposed in my original message (Item (Name, Byte, Bit, Length)) wouldn't require changes to the bytecode, but it's a source language extension:

Compile time semantics: If the current position in the Field (that the compiler obviously is tracking already) is not Byte/Bit, report an error. Otherwise compile the equivalent of "Name, Length,". In particular, Item() doesn't emit Offsets, but expects the developer to add them where required.
Runtime semantics: no change (because the bytecode is identical)
Decompiler behavior: free to choose the syntax since all information can be derived (name, offsets, length): it could always use the original syntax, always the new syntax, some heuristic (maybe to use Item() for the field before an Offset() and use the plain Name, Length, variant otherwise)... There's a trade-off between expressiveness (more location data) and compatibility (with older ASL tools).


Thanks,
Patrick

Am Mi., 3. Apr. 2019 um 23:26 Uhr schrieb Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>:
It’s important for us to hear suggestions so please let us know. If your suggestion is useful for all ACPI firmware developers, we would be more than happy to propose specification changes or add iASL features!

Erik

From: Moore, Robert
Sent: Wednesday, April 3, 2019 12:08 PM
To: Patrick Georgi <pgeorgi(a)google.com<mailto:pgeorgi(a)google.com>>
Cc: devel(a)acpica.org<mailto:devel(a)acpica.org>; Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Subject: RE: [Devel] Field Offset constraints

We do in fact keep tightening up the compiler to check for semantic issues as well as syntax errors. As it stands today, we have 164 errors/warnings/remarks, as well as 13 additional errors for the Data Table compiler, and 11 errors for the preprocessor.

Do you have any additional suggestions?

Bob


From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Wednesday, April 3, 2019 11:08 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>
Cc: devel(a)acpica.org<mailto:devel(a)acpica.org>; Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Subject: Re: [Devel] Field Offset constraints

Hi Robert,

Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>:
2)      Disable the specific remark via the –VW option.
iasl -vw 2158 dsdt.asl   // disable remark #2158
Thank you for the pointer to that option, that's very helpful.

Independent from that, is there interest in providing language features on top of ASL (maybe in revisions to the spec if the tool is meant to remain strictly compliant) to more rigorously express constraints that can be verified at compile time?


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 20734 bytes --]

Re: [Devel] Field Offset constraints

[Patrick Georgi]

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

One (simple) example would be the mapping between
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h#269
that
specifies addresses in EC "RAM" space to
https://review.coreboot.org/cgit/coreboot.git/tree/src/ec/google/chromeec/acpi/ec.asl#n42.
Right now, there's relatively little to ensure that (let's say) "FAND" in
the ASL really points to the same address as EC_ACPI_MEM_FAN_DUTY.

Later in the ASL we use Offset to make sure that the bitfield doesn't
exceed the space it has (line 91), as a very weak assertion that the code
is sane.
The ability to concretely specify where each of these fields is supposed to
end up instead having to count would increase the confidence in the ACPI
side of things.

(If things look a bit odd in the ASL: we run it through cpp to support
#include and #define)


Thanks,
Patrick

Am Do., 4. Apr. 2019 um 22:12 Uhr schrieb Schmauss, Erik <
erik.schmauss(a)intel.com>:

> Hi Patrick,
>
>
>
> I assume that you are trying to translate a specification that contains
> diagrams to this ASL OperationRegion. Could you send us an image of what
> this diagram or specification looks like? We don’t need the exact
> specification. I’m just curious as to what this specification looks like.
> Feel free to blank-out any proprietary or sensitive fields.
>
>
>
> Thanks,
>
>
>
> Erik
>
>
>
> *From:* Patrick Georgi [mailto:pgeorgi(a)google.com]
> *Sent:* Wednesday, April 3, 2019 2:52 PM
> *To:* Schmauss, Erik <erik.schmauss(a)intel.com>
> *Cc:* Moore, Robert <robert.moore(a)intel.com>; devel(a)acpica.org
> *Subject:* Re: [Devel] Field Offset constraints
>
>
>
> Hi Erik,
>
> thanks for the encouraging words.
>
>
>
> As mentioned, I think it would be useful to have a mechanism to lock down
> where a field item ends up.
>
> We used to use Offset() for that purpose to make sure that at least we're
> not putting more into a space than fits into it (because Offset() won't
> move backward), but something more comprehensive (that can also identify
> underflow for example) would be nice.
>
>
>
> The (optional) syntax I proposed in my original message (Item (Name, Byte,
> Bit, Length)) wouldn't require changes to the bytecode, but it's a source
> language extension:
>
>
>
> Compile time semantics: If the current position in the Field (that the
> compiler obviously is tracking already) is not Byte/Bit, report an error.
> Otherwise compile the equivalent of "Name, Length,". In particular, Item()
> doesn't emit Offsets, but expects the developer to add them where required.
>
> Runtime semantics: no change (because the bytecode is identical)
>
> Decompiler behavior: free to choose the syntax since all information can
> be derived (name, offsets, length): it could always use the original
> syntax, always the new syntax, some heuristic (maybe to use Item() for the
> field before an Offset() and use the plain Name, Length, variant
> otherwise)... There's a trade-off between expressiveness (more location
> data) and compatibility (with older ASL tools).
>
>
>
>
>
> Thanks,
>
> Patrick
>
>
>
> Am Mi., 3. Apr. 2019 um 23:26 Uhr schrieb Schmauss, Erik <
> erik.schmauss(a)intel.com>:
>
> It’s important for us to hear suggestions so please let us know. If your
> suggestion is useful for all ACPI firmware developers, we would be more
> than happy to propose specification changes or add iASL features!
>
>
>
> Erik
>
>
>
> *From:* Moore, Robert
> *Sent:* Wednesday, April 3, 2019 12:08 PM
> *To:* Patrick Georgi <pgeorgi(a)google.com>
> *Cc:* devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
> *Subject:* RE: [Devel] Field Offset constraints
>
>
>
> We do in fact keep tightening up the compiler to check for semantic issues
> as well as syntax errors. As it stands today, we have 164
> errors/warnings/remarks, as well as 13 additional errors for the Data Table
> compiler, and 11 errors for the preprocessor.
>
>
>
> Do you have any additional suggestions?
>
>
>
> Bob
>
>
>
>
>
> *From:* Patrick Georgi [mailto:pgeorgi(a)google.com <pgeorgi(a)google.com>]
> *Sent:* Wednesday, April 3, 2019 11:08 AM
> *To:* Moore, Robert <robert.moore(a)intel.com>
> *Cc:* devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
> *Subject:* Re: [Devel] Field Offset constraints
>
>
>
> Hi Robert,
>
>
>
> Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <
> robert.moore(a)intel.com>:
>
> 2)      Disable the specific remark via the –VW option.
>
> iasl -vw 2158 dsdt.asl   // disable remark #2158
>
> Thank you for the pointer to that option, that's very helpful.
>
>
>
> Independent from that, is there interest in providing language features on
> top of ASL (maybe in revisions to the spec if the tool is meant to remain
> strictly compliant) to more rigorously express constraints that can be
> verified at compile time?
>
>
>
>
>
> Regards,
>
> Patrick
>
> --
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>
>
>
>
> --
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 13504 bytes --]

Re: [Devel] Field Offset constraints

[Schmauss, Erik]

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

Hi Patrick,

I assume that you are trying to translate a specification that contains diagrams to this ASL OperationRegion. Could you send us an image of what this diagram or specification looks like? We don’t need the exact specification. I’m just curious as to what this specification looks like. Feel free to blank-out any proprietary or sensitive fields.

Thanks,

Erik

From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Wednesday, April 3, 2019 2:52 PM
To: Schmauss, Erik <erik.schmauss(a)intel.com>
Cc: Moore, Robert <robert.moore(a)intel.com>; devel(a)acpica.org
Subject: Re: [Devel] Field Offset constraints

Hi Erik,
thanks for the encouraging words.

As mentioned, I think it would be useful to have a mechanism to lock down where a field item ends up.
We used to use Offset() for that purpose to make sure that at least we're not putting more into a space than fits into it (because Offset() won't move backward), but something more comprehensive (that can also identify underflow for example) would be nice.

The (optional) syntax I proposed in my original message (Item (Name, Byte, Bit, Length)) wouldn't require changes to the bytecode, but it's a source language extension:

Compile time semantics: If the current position in the Field (that the compiler obviously is tracking already) is not Byte/Bit, report an error. Otherwise compile the equivalent of "Name, Length,". In particular, Item() doesn't emit Offsets, but expects the developer to add them where required.
Runtime semantics: no change (because the bytecode is identical)
Decompiler behavior: free to choose the syntax since all information can be derived (name, offsets, length): it could always use the original syntax, always the new syntax, some heuristic (maybe to use Item() for the field before an Offset() and use the plain Name, Length, variant otherwise)... There's a trade-off between expressiveness (more location data) and compatibility (with older ASL tools).


Thanks,
Patrick

Am Mi., 3. Apr. 2019 um 23:26 Uhr schrieb Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>:
It’s important for us to hear suggestions so please let us know. If your suggestion is useful for all ACPI firmware developers, we would be more than happy to propose specification changes or add iASL features!

Erik

From: Moore, Robert
Sent: Wednesday, April 3, 2019 12:08 PM
To: Patrick Georgi <pgeorgi(a)google.com<mailto:pgeorgi(a)google.com>>
Cc: devel(a)acpica.org<mailto:devel(a)acpica.org>; Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Subject: RE: [Devel] Field Offset constraints

We do in fact keep tightening up the compiler to check for semantic issues as well as syntax errors. As it stands today, we have 164 errors/warnings/remarks, as well as 13 additional errors for the Data Table compiler, and 11 errors for the preprocessor.

Do you have any additional suggestions?

Bob


From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Wednesday, April 3, 2019 11:08 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>
Cc: devel(a)acpica.org<mailto:devel(a)acpica.org>; Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Subject: Re: [Devel] Field Offset constraints

Hi Robert,

Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>:
2)      Disable the specific remark via the –VW option.
iasl -vw 2158 dsdt.asl   // disable remark #2158
Thank you for the pointer to that option, that's very helpful.

Independent from that, is there interest in providing language features on top of ASL (maybe in revisions to the spec if the tool is meant to remain strictly compliant) to more rigorously express constraints that can be verified at compile time?


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado


--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 14595 bytes --]

Re: [Devel] Field Offset constraints

[Patrick Georgi]

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

Hi Erik,
thanks for the encouraging words.

As mentioned, I think it would be useful to have a mechanism to lock down
where a field item ends up.
We used to use Offset() for that purpose to make sure that at least we're
not putting more into a space than fits into it (because Offset() won't
move backward), but something more comprehensive (that can also identify
underflow for example) would be nice.

The (optional) syntax I proposed in my original message (Item (Name, Byte,
Bit, Length)) wouldn't require changes to the bytecode, but it's a source
language extension:

Compile time semantics: If the current position in the Field (that the
compiler obviously is tracking already) is not Byte/Bit, report an error.
Otherwise compile the equivalent of "Name, Length,". In particular, Item()
doesn't emit Offsets, but expects the developer to add them where required.
Runtime semantics: no change (because the bytecode is identical)
Decompiler behavior: free to choose the syntax since all information can be
derived (name, offsets, length): it could always use the original syntax,
always the new syntax, some heuristic (maybe to use Item() for the field
before an Offset() and use the plain Name, Length, variant otherwise)...
There's a trade-off between expressiveness (more location data) and
compatibility (with older ASL tools).


Thanks,
Patrick

Am Mi., 3. Apr. 2019 um 23:26 Uhr schrieb Schmauss, Erik <
erik.schmauss(a)intel.com>:

> It’s important for us to hear suggestions so please let us know. If your
> suggestion is useful for all ACPI firmware developers, we would be more
> than happy to propose specification changes or add iASL features!
>
>
>
> Erik
>
>
>
> *From:* Moore, Robert
> *Sent:* Wednesday, April 3, 2019 12:08 PM
> *To:* Patrick Georgi <pgeorgi(a)google.com>
> *Cc:* devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
> *Subject:* RE: [Devel] Field Offset constraints
>
>
>
> We do in fact keep tightening up the compiler to check for semantic issues
> as well as syntax errors. As it stands today, we have 164
> errors/warnings/remarks, as well as 13 additional errors for the Data Table
> compiler, and 11 errors for the preprocessor.
>
>
>
> Do you have any additional suggestions?
>
>
>
> Bob
>
>
>
>
>
> *From:* Patrick Georgi [mailto:pgeorgi(a)google.com <pgeorgi(a)google.com>]
> *Sent:* Wednesday, April 3, 2019 11:08 AM
> *To:* Moore, Robert <robert.moore(a)intel.com>
> *Cc:* devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
> *Subject:* Re: [Devel] Field Offset constraints
>
>
>
> Hi Robert,
>
>
>
> Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <
> robert.moore(a)intel.com>:
>
> 2)      Disable the specific remark via the –VW option.
>
> iasl -vw 2158 dsdt.asl   // disable remark #2158
>
> Thank you for the pointer to that option, that's very helpful.
>
>
>
> Independent from that, is there interest in providing language features on
> top of ASL (maybe in revisions to the spec if the tool is meant to remain
> strictly compliant) to more rigorously express constraints that can be
> verified at compile time?
>
>
>
>
>
> Regards,
>
> Patrick
>
> --
>
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>


-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 8306 bytes --]

Re: [Devel] Field Offset constraints

[Schmauss, Erik]

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

It’s important for us to hear suggestions so please let us know. If your suggestion is useful for all ACPI firmware developers, we would be more than happy to propose specification changes or add iASL features!

Erik

From: Moore, Robert
Sent: Wednesday, April 3, 2019 12:08 PM
To: Patrick Georgi <pgeorgi(a)google.com>
Cc: devel(a)acpica.org; Schmauss, Erik <erik.schmauss(a)intel.com>
Subject: RE: [Devel] Field Offset constraints

We do in fact keep tightening up the compiler to check for semantic issues as well as syntax errors. As it stands today, we have 164 errors/warnings/remarks, as well as 13 additional errors for the Data Table compiler, and 11 errors for the preprocessor.

Do you have any additional suggestions?

Bob


From: Patrick Georgi [mailto:pgeorgi(a)google.com]
Sent: Wednesday, April 3, 2019 11:08 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>
Cc: devel(a)acpica.org<mailto:devel(a)acpica.org>; Schmauss, Erik <erik.schmauss(a)intel.com<mailto:erik.schmauss(a)intel.com>>
Subject: Re: [Devel] Field Offset constraints

Hi Robert,

Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore(a)intel.com>>:
2)      Disable the specific remark via the –VW option.
iasl -vw 2158 dsdt.asl   // disable remark #2158
Thank you for the pointer to that option, that's very helpful.

Independent from that, is there interest in providing language features on top of ASL (maybe in revisions to the spec if the tool is meant to remain strictly compliant) to more rigorously express constraints that can be verified at compile time?


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7598 bytes --]

Re: [Devel] Field Offset constraints

[Patrick Georgi]

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

Hi Robert,

Am Mi., 3. Apr. 2019 um 19:38 Uhr schrieb Moore, Robert <
robert.moore(a)intel.com>:

> 2)      Disable the specific remark via the –VW option.
>
> iasl -vw 2158 dsdt.asl   // disable remark #2158
>
Thank you for the pointer to that option, that's very helpful.

Independent from that, is there interest in providing language features on
top of ASL (maybe in revisions to the spec if the tool is meant to remain
strictly compliant) to more rigorously express constraints that can be
verified at compile time?


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1783 bytes --]

Re: [Devel] Field Offset constraints

[Moore, Robert]

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

Patrick,

There are two methods to disable this remark:

1)      Disable all remarks via the –VR option

2)      Disable the specific remark via the –VW option.

Please see the examples below.

BTW, remarks from iASL are simply suggestions, they are not nearly as serious as warnings or errors. That is why we provide an option to disable all remarks. Remarks do not affect the AML code that is emitted.



    OperationRegion (OPR1, SystemMemory, 0x200, 0x400)
    Field (OPR1, ByteAcc, Lock, Preserve)
    {
        FIE1, 8,
        FIE2, 8,
        Offset(2),
        FIE3, 8
    }


iasl dsdt.asl

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20190215
Copyright (c) 2000 - 2019 Intel Corporation

dsdt.asl     15:         Offset(2),
Remark   2158 -                ^ Unnecessary/redundant use of Offset operator

ASL Input:     dsdt.asl - 21 lines, 482 bytes, 2 keywords
AML Output:    dsdt.aml - 72 bytes, 2 named objects, 0 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 1 Remarks, 1 Optimizations


iasl -vr dsdt.asl    // disable all remarks

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20190215
Copyright (c) 2000 - 2019 Intel Corporation

ASL Input:     dsdt.asl - 21 lines, 482 bytes, 2 keywords
AML Output:    dsdt.aml - 72 bytes, 2 named objects, 0 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 1 Remarks, 1 Optimizations


iasl -vw 2158 dsdt.asl   // disable remark #2158

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20190215
Copyright (c) 2000 - 2019 Intel Corporation

ASL Input:     dsdt.asl - 21 lines, 482 bytes, 2 keywords
AML Output:    dsdt.aml - 72 bytes, 2 named objects, 0 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 1 Optimizations


From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Patrick Georgi
Sent: Wednesday, April 3, 2019 12:14 AM
To: devel(a)acpica.org
Subject: [Devel] Field Offset constraints

Hi everybody,

at coreboot[1] we use iasl to compile static ASL for various hardware. Recent versions of iasl emit a notice for redundant Offset statements in Fields, apparently with the expectation that they shouldn't exist.

This poses a problem for us since we're sometimes using Offset as a guard, making sure that we didn't inadvertedly shifted fields around (too much), with the expectation that these were redundant in the "good" case.

Since that operator wasn't really suited for that purpose anyway, and now throws warnings (which we try to avoid in our builds), are there plans to add some keyword for compile time constraints checks, or any objections to having such a feature (should one of us decide to implement it)?

Maybe something like

Field (NAME, ByteAcc, Lock, Preserve)
{
    Item(FIE1, 0, 0, 8)
    Item(FIE2, 1, 0, 8)
    Offset(0x10)
    Item(FIE3, 0x10, 0, 8)
}

in which Item(Name, Byte, Bit, Length) would compile to "Name, Length," inside a field after ensuring that the byte and bit offsets match the current location.

Thoughts?

Thanks,
Patrick Georgi

[1] https://www.coreboot.org/
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 18133 bytes --]

[Devel] Field Offset constraints

[Patrick Georgi]

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

Hi everybody,

at coreboot[1] we use iasl to compile static ASL for various hardware.
Recent versions of iasl emit a notice for redundant Offset statements in
Fields, apparently with the expectation that they shouldn't exist.

This poses a problem for us since we're sometimes using Offset as a guard,
making sure that we didn't inadvertedly shifted fields around (too much),
with the expectation that these were redundant in the "good" case.

Since that operator wasn't really suited for that purpose anyway, and now
throws warnings (which we try to avoid in our builds), are there plans to
add some keyword for compile time constraints checks, or any objections to
having such a feature (should one of us decide to implement it)?

Maybe something like

Field (NAME, ByteAcc, Lock, Preserve)
{
    Item(FIE1, 0, 0, 8)
    Item(FIE2, 1, 0, 8)
    Offset(0x10)
    Item(FIE3, 0x10, 0, 8)
}

in which Item(Name, Byte, Bit, Length) would compile to "Name, Length,"
inside a field after ensuring that the byte and bit offsets match the
current location.

Thoughts?

Thanks,
Patrick Georgi

[1] https://www.coreboot.org/
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1833 bytes --]