mangling for fixed point types

[PiJoules]

Hi!

We are attempting to implement fixed point types in clang according to Chapter 4 of the Embedded-C Spec / ISO N1169. This extension includes the addition of up to 24 fixed point types that vary in size, sign, fract/accum, and saturated/not saturated.

signed short _Accum
signed _Accum
signed long _Accum
unsigned short _Accum
unsigned _Accum
unsigned long _Accum
_Sat signed short _Accum
_Sat signed _Accum
_Sat signed long _Accum
_Sat unsigned short _Accum
_Sat unsigned _Accum
_Sat unsigned long _Accum
signed short _Fract
signed _Fract
signed long _Fract
unsigned short _Fract
unsigned _Fract
unsigned long _Fract
_Sat signed short _Fract
_Sat signed _Fract
_Sat signed long _Fract
_Sat unsigned short _Fract
_Sat unsigned _Fract
_Sat unsigned long _Fract

The standard though does not specify mangling when using these types in C++, so usage of these types is limited to C.

Any suggestions for neatly mangling these types?

For now, we can do something along the lines of u7fixed00 to u7fixed23 or u4SulA (for _Sat unsigned long _Accum as an example), but would like to see what other people's thoughts are.

[zygoloid]

Is it expected that the allocation of bits as integer bits and fractional bits would be defined by the target, or should that also be included in the mangling? I'm assuming this is determined by the target.

I don't like either of the suggested approaches. The most obvious available space for a mangling here is encodings beginning with D. So how about:

<builtin-type> ::= [DS] DA <builtin-type> # [_Sat] T _Accum
<builtin-type> ::= [DS] DR <builtin-type> # [_Sat] T _Fract

For example:

signed short _Accum -> DAs
_Sat unsigned long _Accum -> DSDAm
_Sat unsigned short _Fract -> DSDRt

This anticipates DS being permitted in other places, and/or other overflow qualifiers being added eventually; for instance, a _Sat int type is meaningful and might be useful, as might a _Wrap qualifier. If we don't want to plan for that, then DA_ and DR_ would work as encodings for _Sat T _Accum and _Sat T _Fract, respectively.

[PiJoules]

The integer and fractional bits are determined by the target.

Does the <builtin-type> in the expansion imply that builtin types other than signed/unsigned short/long are allowed to be mangled with _Sat and _Accum/_Fract? We only intend to add the types given above and will not be adding other types like _Sat int _Fract. We throw errors during the Sema stage on finding types like these.

The _Sat qualifier won't also be used with other types and can only be used with _Fract and _Accum, so would the grammar then change to

<builtin-type> ::= DA <builtin-type> # T _Accum
<builtin-type> ::= DR <builtin-type> # T _Fract
<builtin-type> ::= DA_ <builtin-type> # _Sat T _Accum
<builtin-type> ::= DR_ <builtin-type> # _Sat T _Fract

[zygoloid]

Does the in the expansion imply that builtin types other than signed/unsigned short/long are allowed to be mangled with _Sat and _Accum/_Fract?

It's just a shorthand to avoid needing to explicitly list the six options.

We only intend to add the types given above and will not be adding other types like _Sat int _Fract.

The idea would be that _Sat signed _Fract is mangled as DSDRi (that is, it gets the mangling that would have been used for _Sat int _Fract if such a type existed).

The _Sat qualifier won't also be used with other types and can only be used with _Fract and _Accum

You have no way to know that. An implementation could very reasonably choose to allow it in other places as an extension.

[PiJoules]

I see, so it's better to have mangle rules that cover different syntactic type combinations even if the type is invalid? (ie. _Sat float _Accum can still have a corresponding mangle even though it is currently an invalid type)

[zygoloid]

I don't see any particular problem with there being combinations of mangling productions that don't correspond to any valid source program (that's actually really common, eg _Z1fA3_Ri). But I think it'd also be fine to describe the rule as:

<builtin-type> ::= [DS] DA <fixed-point-size> # [_Sat] T _Accum
<builtin-type> ::= [DS] DR <fixed-point-size> # [_Sat] T _Fract
<fixed-point-size> ::= s # short
<fixed-point-size> ::= t # unsigned short
<fixed-point-size> ::= i # plain
<fixed-point-size> ::= j # unsigned
<fixed-point-size> ::= l # long
<fixed-point-size> ::= m # unsigned long

[Note: I moved the DS to the start -- I think that makes more sense, as it's more like a type qualifier in some sense. I've also retroactively made that change to my prior comments.]

But I don't want to get bogged down with how we specify the rule. The thing to focus on right now is what rule we use. Does the one in this comment seem OK to you?

[PiJoules]

Those rules look fine to me. Thanks! Is there anything else I would need to do to see this in a future ABI?

[rjmccall]

Could you open a PR for this and make sure it's linked here?

[PiJoules]

Sorry for the delay. I have #161 ready. I'm not familiar with github PRs though to know how to reference this issue with that PR.

[PiJoules]

Friendly ping on this. How does this PR look to you?

[PiJoules]

This was merged in #161