Hi Alex!
W dniu 28.06.2023 o 03:54, waffl3x pisze:
I want to preface this stating that I have little to no experience in compiler
development, I am only merely just getting into it. With that said, I have
messed around
with library design a fair amount, and this seems like something that could be
implemented in a library. It might be slightly comfier implemented on the
compiler side,
but I question how generally it could be implemented.
I thought of it a lot, and library implementation is something I'd
rather avoid. Before I elaborate, let me put some excerpts of the code
in question. GREP-ing the sources for "->next" (list processing) this is
how it looks like. I have a lot of code like this scattered around:
-------------------
y->next = NULL;
if (our) { out->next = a;
for (y = t->HD; y && y->next; y = y->next)
if (y) y->next = a;
fit->HD = a->next;
fit->win = a->next;
b = a->next;
--------------------
This is from just one source file, which otherwise is "plain C". If I
was to put it into a library that use "asm tweaked fancy pointers", a
portable fragment of code becomes "target dedicated" - this is undesired.
To elaborate: even in (or may be "particularly" in) embedded world, one
prefers to have as portable code (to other targets) as possible. And I
must say, that such code fragments as quoted are scattered around my
sources practically everywhere. If I "convert" them to a library, the
entire project becomes "target locked", and in consequences
"unmaintainable". Such move practically kills it.
Now, let me put the case into numbers: if I use stm32f030 instead of
stm32f103, I may end up with just 4kB of RAM. The struct I heavily use
here is 32bytes long, but with 16-bit "pointers" it collapses to
16bytes. This structure pops up in many places and within a running
system it may reach 100 instances. It's a LOT of space to fight for.
-R
PS: pls CC the response to my address (as you have done) - I'm not sure
if I get mails from the list.
