On Mon, 2020-06-01 at 22:50 -0700, Timo Kokkonen wrote:
>
> On Mon, Jun 1, 2020 at 12:21 AM Gerhard Sittig <gerhard.sit...@gmx.net> wrote:
> > [ ... ]
> > Common support for endianess conversion?
>
> Sorry, I meant 'serializers', didn't seem to find anything with
> quick find/grep on sources....
You may have noticed there is the "simple, one-shot" RL16() et al
group of accessors. And the "stream like" *_inc() variants which
I added after finding myself repeating the read/write access
_and_ the address increment too many times, which "just felt
wrong" to me. Depending on your specific use case (fixed layout,
or variable layout and "more of a stream") you may prefer one or
the other, or pick by the mood of the day.
> Btw, looking the endian conversion routines they all seem to "suffer"
> some kind of compiler warning fix (?)
>
> For example:
> static inline uint32_t read_u32le(const uint8_t *p)
> {
> uint32_t u;
>
> u = 0;
> u <<= 8; u |= p[3];
> u <<= 8; u |= p[2];
> u <<= 8; u |= p[1];
> u <<= 8; u |= p[0];
>
> return u;
> }
>
> Seems as if "u = 0" has been added later to fix compiler waning about using
> uninitialized variable, etc? Making the first "u <<=8;"
> unnecessary/redundant....
Not sure what you perceive as "afterthought" there, or
"workaround" for potential compiler warnings. The code was
written that way from the start, by design, for good reasons. Not
a second was spent on dropping the initial zero assignment, or
not putting it there at all.
Let's see why. Gotta change from LE to BE format? Just swap the
lines which collect the bytes. Gotta create a 32bit reoutine
after 16bit support exists? Just add two more lines. Need to
support funny alternatives to ABCD and DCBA, like BADC? Just swap
the lines. Found a typo/braino in the implementation? Just
arrange the lines in the correct order. Simple manipulation,
straight diff, easy to read, easy to reason about, keeps working
reliably, etc etc. Spent some time typing the characters? Count
them, didn't take one second. How much more often is the code
read, and needs to be pondered on? Takes a lot longer.
Computers are good at boring stuff. Constant folding (the 0 << 8
expression) are bread and butter to them. As a human I only have
limited resources, and suck at juggling dozens of things in my
head. So I'd rather concentrate on the application perspective,
and leave the tedium to the machine. Try to be extra smart, and
you end up outsmarting yourself. That's why I hate exceptions,
especially when they are unnecessary (think trailing comma, order
of include directives, and others). There are some things that
humans just should not have to spend precious conscious resources
on. They got other things to do, and can use these resources in
more productive ways.
> Or am I missing something? Minor detail really, was just wondering if
> if I'm not seeing something obvious...
> (good compiler probably will optimize it away though...)
That's the very point of these inline routines. Better optimizers
may not even shift at all, or access individual bytes, do any
math, etc etc. They may just pick the one machine instruction
which "does just that" and be done. I don't care how compilers
translate the source to machine opcodes (though I trust that
today's compilers grok these phrases very well, and know what
they intend to do). All I want is the thing to work, and reliably
so. And then forget this foundation stuff and do the real work in
the application layer.
If you want to help, review and extend the test sequence for the
endianess conversion. Getting more coverage is highly desirable.
Spotting potential issues in the current implementation (from the
caller's perspective) is as beneficial as increasing confidence
in the existing code.
If you are curious, give the source to the godbolt compiler
explorer. Disclaimer: I haven't, just assumed that these phrases
map well to CPU instructions. Call it an educated guess.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
