[Libre-soc-bugs] [Bug 550] binutils support needed for svp64

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=550

--- Comment #80 from dmitry.selyutin at 3mdeb.com ---
What exactly is non-portable with bitfields here, having GCC-compatible
compilers in mind? You don't memcpy the structures, you don't send these over
the network; in fact, the machine where the code was compiled is exactly the
same which runs it. Sure, 64-bit integer bitfields are not ANSI C blessed, but
the code is already GCC-compliant (__attribute__ et al.). The only argument
which stands is least surprise principle (i.e. that other bits use the macros).
But "x->y" is much more readable than "X_GET_Y(x)", and same stands for
setters. Anyway, that's not difficult to change.

As for a lot of 64-bit integers: I don't get where you find 25 uint64_t fields.
There's no need to assign something other than "const struct svp64_entry *" in
PPC opcode structures. The only way these are used are mapping these into the
hash table. Even if there is a need to stick to a single 64-bit integer, you
_can_ still pack bitfields of 64-bit integers into single 64-bit macros, like
you suggest above. My point, however, is readability: unless there are some
portability concerns, there's no need to make it less readable, be it
machine-generated or not.

So I'll think about macros (though I personally find their use for such purpose
quite awful outside of e.g. network programming), but mostly because of least
surprise principle. I'm not convinced of other reasons. As for having a copy of
uint64_t in PPC, I think there must be a pointer to SVP64 entry.

-- 
You are receiving this mail because:
You are on the CC list for the bug.