On Wed, 28 Jun 2023, 08:14 Rafał Pietrak via Gcc, <gcc@gcc.gnu.org> wrote:

> 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.
>

If you use a C++ library type for your pointers the syntax above doesn't
need to change, and the fancy pointer type can be implemented portable,
with customisation for targets where you could use 16 bits for the pointers.



> 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".


Not if you use a C++ class type.


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.
>