[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 #82 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #81)
> no: to repeat again: there is no need. if it was more than 64 bits of
> information, then yes a pointer would be needed.  i have said three
> times that there will never be more than the 64 bits of information.

imho, if that struct is not public API with backward compat constraints, then
just use a struct with bitfields but without the extra pointer. bitfields
produce the exact same machine code as lkcl's macros but are waay more clear
imho. if we run out of space in the future it's pretty easy to refactor it to
use indirection if needed. because the bitfields are always only accessed by
reading/writing through that struct, it doesn't matter if the fields are laid
out non-portably...the compiler generates the code that adapts between the
non-portable fields and the rest the C code. non-portable field layout only
matters when there's a way to access the fields either without using that
struct or from a different cpu architecture.

e.g.:
typedef struct {
    // no pointers...
    uint64_t field1 : 3;
    uint64_t field2 : 3;
    uint64_t field3 : 3;
    uint64_t field4 : 3;
} my_struct;

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