Coding style on bitfields usage and pointers to structures

Coding style on bitfields usage and pointers to structures

[Dmitry Selyutin]

Hi folks,

we're extending PowerPC architecture with Cray-style vectors[0]. One of 
our next objectives is to add support to binutils[1]. Since we maintain 
machine-readable specs, we decided to let our scripts generate the 
entries so that we then reuse them in C code.

I've so far implemented something like this:

struct svp64_entry {
     const char *name;
     uint64_t in1 : 3;
     uint64_t in2 : 5;
     uint64_t in3 : 3;
     uint64_t out : 3;
     uint64_t out2 : 3;
     uint64_t cr_in : 4;
     uint64_t cr_out : 3;
     uint64_t sv_ptype : 2;
     uint64_t sv_etype : 2;
     uint64_t sv_in1 : 3;
     uint64_t sv_in2 : 3;
     uint64_t sv_in3 : 3;
     uint64_t sv_out : 3;
     uint64_t sv_out2 : 3;
     uint64_t sv_cr_in : 3;
     uint64_t sv_cr_out : 3;
     uint64_t : 15;
};

The name can be something like "add" (incorporating "add.", "addo" and 
other variants); the rest of the fields are PPC/SVP64 information (in 
fact they're enumerations). There are about 300 entries to be produced. 
Every svp64_entry is to be bound to one or more entries of 
powerpc_opcode structure at ppc_setup_opcodes() (i.e. upon startup): I 
simply intend to extend `struct powerpc_opcode` with `struct svp64_entry 
*entry` field, initially NULL, and then update this field with a pointer 
to a real SVP64 entry (we generate an array of these).

Our questions are:
1. Does the use of bitfields seems legit here? They simplify the 
reading, but I kinda get an impression that binutils tend to avoid 
bitfields, preferring macros.
2. Would it be OK if we extend `powerpc_opcode` with a pointer to 
structure? Another alternative is to pack all fields into 64-bit integer 
and generate a couple of get/set macros (which to me looks like a 
complication).

The instructions on reproducing the exact output are complex, so, if 
you're interested, I'd like to put these in another e-mail. I created 
two pastes for your convenience, one for the header we generate[2], and 
another for the source code itself[3]. The generation script resides in 
openpower-isa repository[4].

Thank you for your help and advice!

[0] https://libre-soc.org
[1] https://bugs.libre-soc.org/show_bug.cgi?id=550
[2] https://pastebin.com/T2xdHQRe
[3] https://pastebin.com/Mku1T2TE
[4] 
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_binutils.py

-- 
Best regards,
Dmitry Selyutin

Re: Coding style on bitfields usage and pointers to structures

[Dmitry Selyutin]

On 1/18/22 08:45, Dmitry Selyutin wrote:
> we're extending PowerPC architecture with Cray-style vectors[0]. One of 
> our next objectives is to add support to binutils[1].
I forgot to mention that we maintain a fork of binutils-gdb 
repository[0], so you might opt to take a look at what we did so far on 
binutils side (branch svp64).

[0] https://git.libre-soc.org/?p=binutils-gdb.git;a=summary

-- 
Best regards,
Dmitry Selyutin

Re: Coding style on bitfields usage and pointers to structures

[Alan Modra]

On Tue, Jan 18, 2022 at 08:45:47AM +0300, Dmitry Selyutin wrote:
> Our questions are:
> 1. Does the use of bitfields seems legit here? They simplify the reading,
> but I kinda get an impression that binutils tend to avoid bitfields,
> preferring macros.

Bitfields are fine.  C99 is allowed nowadays.  A lot of bfd and
opcodes is very old code from K&R days.

> 2. Would it be OK if we extend `powerpc_opcode` with a pointer to structure?

Sounds reasonable.

-- 
Alan Modra
Australia Development Lab, IBM