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