[PATCH] opcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static const

[Richard Earnshaw (lists)]

On 29/07/2025 10:03, Jan Beulich wrote:
> On 29.07.2025 10:57, Richard Earnshaw (lists) wrote:
>> On 29/07/2025 07:53, Jan Beulich wrote:
>>> On 28.07.2025 18:10, Richard Earnshaw (lists) wrote:
>>>> On 28/07/2025 16:58, Jan Beulich wrote:
>>>>> ---
>>>>> I further wonder whether the struct fields being unsigned int isn't
>>>>> wasteful - unsigned char (or bool for "is_reserved") would appear to
>>>>> suffice, without negatively affecting generated code (except on
>>>>> architectures where byte loads are more expensive).
>>>>
>>>> uint8_t would be fine and preferable to (unsigned) char since it's a value not a character.
>>>
>>> I can use uint8_t, but personally I recommend to avoid fixed-width types
>>> where they can be avoided. They will only cause problems on architectures
>>> which have no way to express those types. (E.g. on TI C4x and C54x I
>>> wonder how uint8_t would be expressable, with them having 32 / 16 bits
>>> per byte respectively.) The "not a character" argument imo only applies
>>> to uses of plain char; signed or unsigned forms thereof are normal (just
>>> narrow) integer types according to my understanding).
>>
>> If space is a concern then I'd just use a bitfield.  Performance isn't critical here, so
> 
> Okay, if bitfields are okay to use here, I'd indeed prefer going that route.
> 
>>  struct
>>     {
>>       bool is_reserved      : 8;
> 
> I don't think a bool bitfield can be other than 1 bit wide, though. I'd put
> the field ...

I don't see why they couldn't be.  Other bitfields can be wider than they're type: eg

uint16_t x: 24;

is legal, it just adds padding.

> 
>>       unsigned num_regs     : 8;
>>       unsigned num_elements : 8;
> 
> ... last then.

But this is ok too.

R.

> 
>>     } data [] =
>>
>> Would be just fine; on most machines that will just become byte loads anyway.
> 
> Indeed.
> 
> Jan