Re: [Devel] Field Offset constraints

[Schmauss, Erik <erik.schmauss at intel.com>]

[-- 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 --]