Re: [Devel] Field Offset constraints

[Patrick Georgi <pgeorgi at google.com>]

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