Re: [Dwarf-discuss] Dwarf language code for P4 langauge

[Robinson, Paul via Dwarf-discuss]

Thanks. CC’ing the list as that’s what we use for the record of requests.
--paulr

From: Chris Dodd 
Sent: Sunday, July 28, 2024 1:38 AM
To: Robinson, Paul 
Subject: Re: [Dwarf-discuss] Dwarf language code for P4 langauge

For P4, the lower bound for arrays is 0, and the versioning scheme is VVMMPP 
(current latest version is 010204 - 1.2.4 published last year though there will 
likely soon be a 1.2.5 version)

On Sat, Jul 27, 2024 at 1:46 AM Robinson, Paul 
mailto:paul.robin...@sony.com>> wrote:
It’s not written down anywhere (probably should be) but in order to assign a 
new language code, we need some additional information. Specifically, we need a 
default lower bound for arrays (as seen at 
https://dwarfstd.org/languages.html
 ) and for the upcoming DWARF v6, a versioning scheme (as seen at 
https://dwarfstd.org/languages-v6.html
 ).
--paulr

From: Dwarf-discuss 
mailto:sony@lists.dwarfstd.org>>
 On Behalf Of Chris Dodd via Dwarf-discuss
Sent: Thursday, July 25, 2024 8:52 PM
To: dwarf-discuss@lists.dwarfstd.org
Subject: [Dwarf-discuss] Dwarf language code for P4 langauge


I'd like to request the allocation of a new language code for the P4 language 
(https://p4.org/).
  Is there a standard process for this, or a different place it should be 
requested?

Chris Dodd
cd...@nvidia.com
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds

[David Blaikie via Dwarf-discuss]

On Sat, Jul 27, 2024 at 10:50 PM Alexandre Oliva  wrote:

> On Jul 27, 2024, David Blaikie  wrote:
>
> > If I'm following correctly, Alexandre - you're suggesting a situation
> where
> > an instance of a type, when it appears within a packed struct, may become
> > smaller than it would otherwise be?
>
> It's a philosophical question whether it's smaller in a packed struct or
> larger otherwise, a bit like whether the Tardis is bigger in the inside
> or smaller on the outside ;-D, but fact is that both kinds of uses of
> the same type can be common in a unit, so it would be desirable to
> represent those types with their sizes once, rather than e.g. override
> it at every variable or field.
>
> Right now, we represent two distinct, unrelated types to that end.  ISTM
> that it would be better to be able to relate them, using one as the base
> type for the other.  Sharing the bounds would be desirable, but it's not
> clear that omitting them in the derived type would achieve the desired
> result.  That's what this thread is about.
>
> > (usually in C that's not the case -
>
> *nod*, the issue at hand came from Ada.
>
> > If you have a language where "packing" a member might cause it to become
> > smaller, not just cause the leading/trailing padding to be omitted -
> > perhaps that'd be better modelled, not with a new/distinct type, but with
> > the same mechanism as is used for bitfields in C? ie: using bit_size and
> > data_bit_offset?
>
> The situation is not very different, but in Ada one can specify the
> target size (in bits) for the type (which may require biased
> representations, but that's besides the point).  Despite the specified
> size, standalone variables and members of unpacked types use full
> storage units, unless packing is requested.  See
> e.g.
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gnat.dg/bias1.adb


I see, so do I understand correctly that you'd prefer not to use the
bitfield style representation, because it'd be repetitious? (having to put
it on every member of that type when packed?) Or are there other problems
with it?
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss