<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 9, 2018 at 11:19 PM, Gert Wollny <span dir="ltr"><<a href="mailto:gw.fossdev@gmail.com" target="_blank">gw.fossdev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Am Montag, den 09.04.2018, 14:03 -0400 schrieb Marek Olšák:<br>
> On Mon, Apr 9, 2018 at 10:51 AM, Bas Vermeulen <<a href="mailto:bas@daedalean.ai">bas@daedalean.ai</a>><br>
> wrote:<br>
</span>Which solution is better depends on what is done more often: reading<br>
the index or writing to the bit fields.<br></blockquote><div><br></div><div>The bitfields are read and written, and the index is mostly read. I found</div><div>four instances of the bitfields being written after which the index needs to</div><div>be updated.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > I am working on a new version of this patch. I have one version<br>
> > which does away with all the bitfields, and uses functions to<br>
> > update the index.<br>
</span>This emulates the code the compiler would create, but it requires that<br>
for each bit field setters (and getters?) must be implemented.<br></blockquote><div><br></div><div>Yes. I have a git branch with this change ready if that's what's wanted/needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > Another approach would be to change the union to a struct, and use<br>
> > a function to get the index.<br>
</span>This method has the advantage that only the access to the index needs<br>
new implementation.<br></blockquote><div><br></div><div>I can prepare a patch for this as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > Yet another approach would be to keep the contents of the union and<br>
> > the index in one struct, and use a function to<br>
> > (re)calculate the index.<br>
</span>I don't think that would make much sense.<br></blockquote><div><br></div><div>It adds four lines to the code, all the key->u.xxx has it's u. removed.</div><div>But future implementation needs to remember to call that function if any of</div><div>the bitfields are changed. Which can be annoying.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is another option: Check at configuration time whether the bit<br>
field layout is like the low or the high endian layout you already<br>
implemented, and instead of basing the selection of the struct layout<br>
on the big/low-endianess of the architecture, base it on this test.<br>
<br>
It would probably be prudent to test both layouts and then fail<br>
configuration if non of the two reflect the actual layout (at which<br>
point one would have to thing about how to implement all the bit<br>
shifting properly).</blockquote><div><br></div><div>Or just keep the union dependent on endianness, and add an assert/check/test</div><div>to make sure that everything works as expected.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> ><br>
> > Which would you prefer?<br>
> ><br>
><br>
> I don't mind bitfields. They make the code nice and tiny. Shifts<br>
> would decrease readability.<br>
</span>The problem is, that the layout of bitfields is compiler dependend.<br></blockquote><div><br></div><div>Let me know what you guys want to have this included. I just want it fixed,</div><div>I don't really care on the form. :)</div><div><br></div><div>Bas Vermeulen</div></div></div></div>