On 29/05/2026 22:16, BGB wrote:The main place it makes a difference is global arrays from a translation unit that is included, but for functions that are not included.On 5/29/2026 6:22 AM, David Brown wrote:That is the point of them, yes. "-ffunction-sections" can be useful at removing unused code from more general code. For microcontrollers, SDK's and manufacturers' driver code will normally contain a large number of functions that can be eliminated in this way, saving a lot of code space.On 29/05/2026 12:20, BGB wrote:>On 5/29/2026 2:52 AM, Janis Papanagnou wrote:>On 2026-05-28 11:57, BGB wrote:On 5/28/2026 2:18 AM, Janis Papanagnou wrote:[...]On 2026-05-28 01:49, BGB wrote:>>>>
But, not really an "easy" way to avoid bloat, other than to write code specifically for what cases are relevant; while also avoiding needless duplication and copy paste (where, overuse of copy/paste can also lead to bloat; along with turning the code into an ugly mess).
Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler)
to deposit template code for linking. In the later days I've not
seen such immature things anymore.
>
Possibly, a lot could depend on how one is counting things as well.
>
>
In a lot of cases when using GCC, I end up using:
-ffunction-sections -fdata-sections -Wl,-gc-sections
On many targets, "-fdata-sections" can lead to noticeably larger and slower code because it effectively eliminates section anchor optimisations. It does not negatively affect x86 AFAICS, because x86 does not use section anchors.
>
<https://godbolt.org/z/zeoq41Y7d>
>
With -fsection-anchors (enabled with optimisation on targets that support it - generally RISCy load/store architectures), program- lifetime variables are kept together in a lump (as though they were in a struct) and often addressed by a pointer to that pretend struct. Thus if a function accesses two variables "a" and "b", instead of having to load the addresses of each of "a" and "b" into separate registers, it loads an "anchor" into one register and accesses the variables with reg+offset addressing.
>
I've seen "-fdata-sections" used regularly in embedded systems - it is almost always a bad idea.
>
("-ffunction-sections" is often very helpful to reduce code image size, so keep that one.)
>
Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's output at least sorta space-comparable to my own compilers.
>
The merit of "-fdata-sections" is mostly that it eliminates unused global variables; whereas "-ffunction-sections" eliminates unreachable functions.
However, in practice, "-fdata-sections" rarely eliminates a significant amount - most programs do not have large amounts of statically-allocated data that is not used. Gcc, and I think most other compilers, put the static lifetime data for each translation unit in its own section, so if no data from a translation unit is used it will be eliminated at link time even with -fno-data-sections. And of course it makes no difference for heap data or stack data.
Also functions with large static arrays.
void SomeFunc()
{
static char buf[4096];
...
}
Where, say, eliminating SomeFunc does not necessarily eliminate buf.
In my testing, "-ffunction-sections" is absolutely worth using (on targets where code space is relevant - there's no need for PC software). On some targets, it may mean a few lost opportunities for shorter jump/call instructions between functions in the same translation unit, but the cost is rarely anything more than a slightly longer link time. But "-fdata-sections" typically gives almost no ram space savings, and makes code bigger and slower.It depends on the way it is built.
As I noted, gcc on x86 does not support section anchors, so there is not likely to be much code cost for -ffdata-sections.
Where section anchors shine - and where -fdata-sections therefore has cost - is when a function needs to access more than one piece of static lifetime data defined in the same translation unit (or another translation unit if you are using LTO). That happens a lot in embedded ARM programming at least. I don't know about RISC-V. If the target normally uses a "small data section" for ram (I know this is common on PowerPC), then there is, in effect, a program-wide section anchor already. So it is possible that it relatively few targets have section anchors - but the 32-bit ARM on gcc is a vastly popular choice in the embedded world, so it is important to understand the cost of this compiler flag for that target at least.
A lot of times though (for non-relocatable static-linked binaries) it mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global variables. There is a Global Pointer that needs to be loaded when the binary is started, unclear what it is used for exactly.
in PIC/PIE binaries, it uses AUIPC+ADDI to get a GOT pointer and then uses the GOT pointers to access global variables (via fetching the address of the variable from the GOT).
Can note that BGBCC targeting RV works differently, instead using GP to access global variables, and clustering the commonly accessed global variables around GP (GP is initialized to point towards at the start of the ".data" section for the main EXE at program startup, though in my ABI this may actually be a copy allocated elsewhere in RAM, and not actually pointing at the version of the section located in the original PE image; note that the loader also applies base relocs for the data section separately when locating it; in effect the base relocs being internally partitioned per-section, rather than the per-page partitioning scheme used in the original PE/COFF).
For my target, I mostly end up needing to use PIE binaries with GCC, as it needs to be able to load the binary at different locations.
However, I am using a custom C library, as I (still) haven't managed to get the "ld-linux.so" stuff working. Not yet figured out whatever poorly-documented arcane dark magic is needed to get this part working.
As noted, my compiler's output (including for plain RISC-V) using PE/COFF, which was also the native format for the OS.
Note that for Linux binaries in this case it would mimics the Linux syscall interface; though as I hadn't gotten very far with the PIE loader, most of the syscalls are still not implemented.
My own makeshift OS has a different syscall mechanism, ironically using the same registers, but a syscall number of -1 (Linux uses positive syscall numbers).
They work in different ways, IIRC:
X10..X15: Arg1..Arg6
X16: Unused, 0
X17: Syscall Number (always positive)
In my case, syscalls took a different form, IIRC:
X10: Object ID (Handle)
X11: Method Number (Integer)
X12: Method Args List (Pointer)
X13: Return Value (Pointer)
X14..X16: Unused, 0 (RV)
X17: Holds -1 (RV).
In this case, system calls and many OS APIs take the form of object method calls, with a special range of low-numbered object IDs (Eg, 0 or NULL) mapping to core/basic syscalls.
But, yeah, some OS APIs would take the form of objects which would be wrapped in a VTable struct, say:
SomeApi_Vt **api;
(*Api)->ApiMethod(api, arg1, arg2);
In this case, well, there were two major ways of requesting APIs:
Pairs of EIGHTCC values, for some public APIs
Or as FOURCC's for shorthand (zero padded to 64 bits).
As a UUID / GUID:
Primarily used for local / private interfaces.
Well, people probably can't guess where this mechanism originally came from...
Well, not exactly the same as the inspiration, as there is no IDL compiler involved, mostly just bare C structs representing the VTables. There is essentially a blob of generic reusable method-wrappers (and a whole generic reusable VTable) that is shared across many of these objects, so calling a method on an object then just sorta translates it into the corresponding system call to invoke that method slot.
Well, and this mechanism being part of why (for RV) I stuck with an ABI variant that passes everything in X registers (separate X and F registers would make a big ugly mess for this whenever a method has a floating-point argument).
Depends on what target I am building for:>[...]
Neither is needed with my own compiler, which compiles things in a way such that it eliminates anything that is unreachable.
I don't tend to think of MSVC as a highly optimising compiler - but it is not a tool I have much use for, as it does not handle the targets I need. When I have sometimes looked at the generated code on godbolt, it has not impressed me at all. So it could well fall into the "helpful when using a weaker compiler" category.>>
That might be the case for a very simplistic compiler. With an optimising compiler, these extra variables will quickly be eliminated. If the compiler has a good scheduling model of the device, it do whatever instruction scheduling works best for that processor. If the model is not good enough, it will be suboptimal. I would not, however, expect any different in the generated code for the two code snippets.
>
Sometimes this kind of "manual optimisation" is helpful when you have to try to get efficient results from a weak compiler, however.
>
Possibly, but this sort of thing can help with both BGBCC and with MSVC IME
Windows Native: Typically MSVC
WSL: Usually GCC or Clang
Seems to have: GCC 13.2.0; Clang 18.1.3
RISC-V GCC: Also 13.2.0 (also via WSL)
Linux: Typically GCC
I rarely much use Cygwin anymore, as it was mostly rendered obsolete by WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.
For BGBCC, it can build both on native Windows and on Linux/WSL (though recently noted that this build was broken, mostly by GCC and Clang being more pedantic about missing prototypes, and a few prototypes were being missed by my function-prototype mining tool). Went and fixed this, but haven't posted this yet.
As for optimizing in MSVC, yeah, it is in the area of not terrible, but not super clever either.
If one expects the sort of high-level code-rewriting cleverness that GCC or Clang often does, one will be disappointed.
But, sometimes, the main "heavy hitter" optimizations are things like constant-folding and register allocation, which it does do effectively.
Though, both MSVC and BGBCC seem to use one sort of strategy for register allocation:
Static assign things to callee-save registers and use remaining registers for dynamic allocation within basic-blocks. Variables with finite non-overlapping lifetimes (that do not cross basic-block boundaries) may potentially share a register (this more generally applies to things like temporaries).
And, GCC and Clang use another: Assign dynamically but carry values across basic-block boundaries along control-flow paths.
Both tend to give different patterns though, and seem to favor different types of code.
It is more tradition...>They should not do so (IMHO, of course). Yes, macros are traditional - but there are no plus sides to using them for this kind of thing. (There are no plus sides to using all-caps either, but people do that too.)>>>>>>>
Usual strategy is to try to limit how much code is written, and also to avoid doing things in ways that result in too much code, or too much cruft.
>
Best to avoid both copy paste when reasonable, and sticking anything non-trivial in macros.
We avoided macros if possible.
>
They are de-facto for constants and similar, but for longer stuff is better avoided.
Macros are rarely the best way to define constants. They are needed if you are using the constants for pre-processor stuff like conditional compilation. But generally you get clearer code, better typing, and potentially several other benefits from using alternative choices like "enum" (even for stand-alone integer constants), "static const" variables, and in C23, "constexpr" variables. There's no doubt that a lot of code /does/ use macros for constants, but I view it as a relic of the past rather than good coding practice.
>
They are traditional...
>
Like:
static const double M_PI = 3.14159265358979;
>
Could also make sense, but people don't do usually this, they usually use macros...
My conventions, as noted, are sorta like:
Macros / Constants: All caps;
Functions:
LIBNAME_SysSys_FirstLetterCaps //externally callable within LIBNAME
libname_subsys_nocaps //usually private to a subsystem
LIBNAME_FirstLetterCaps //main API for a private library
somefunction //C library convention
libname_somefunction //some OS API stuff
libFirstLetterCaps //GL-like, common for public APIs
FirstLetterCaps //was common in Win32 API, unused
Conventions are looser for standalone programs, but:
somename, some_name, ... //small programs
S_SomeFunc //id Software like, letter for major subsystem
In my own makeshift OS, had used OpenGL like naming for a lot of OS APIs.
tkWhatever //TestKern OS APIs
tkgdiWhatever //TKGDI: Basically Graphics/GUI stuff
As noted, some amount of these are implemented as object wrappers.
Likewise for my OpenGL implementation.
Though, OpenGL is more annoying in that it usually works via a "GetProcAddress()" type mechanism, so you need to fetch each function pointer internally (and provide a lookup mechanism for each function). Where, the main (static linked) part of the GL API is effectively wrapper functions over function pointers gained via said "GetProcAddress()" mechanism, which then go into the userland implementation of those functions (typically, with part of the GL API running in userland, and a backend part that runs "elsewhere", such as in the GUI process, and is reached over an Object / COM interface).
FWIW, I didn't design this part of the GL API, but if I had, probably would have just used COM objects internally.
Still better IMO to provide a nice C API wrapper over said COM objects though, rather than go the DirectX route and be like "Hey, application code, have fun with these here bare COM objects!".
Exposing bare COM objects and GUIDs in a public API is poor design IMO.
Well, even if in effect many of the API calls are just:
void apiDoSomething()
{ (*someapi_context)->DoSomething(someapi_context); }
This differs some from Linux APIs, which often like sharing bare functions and variables across API boundaries (so, no real wall of separation between the library and application in this sense).
These partly runs into an issue in that in my case, BGBCC (like MSVC) requires being explicit about DLL imports and exports, and sharing global variables across DLL boundaries is generally discouraged.
Note that the DLL mechanism doesn't actually support sharing global variables directly, so if you try to share a global across a DLL boundary, what you actually get is a hidden function-call that returns a pointer to the variable.
__declspec(dllimport) int somevar; //not actually a variable.
x=somevar;
Is more like:
x=*(int *)(__get_somevar());
But, generally discouraged.
Sharing variables across DLLs is bad practice IMO, and ideally only sharing functions that represent a public API (and not, "whatever random stuff happens to be in the library"). Contrast to the Linux "shared object" approach which does tend to take more of a "share everything" approach, and libraries tend to not maintain as string of a library/application separation.
Well, and then Cygwin goes and tries to fake Linux behavior on top of DLLs (in which case a large library can also find itself running into the hard limit on the maximum number of DLL exports).
...
Can note that I had approached C library linking in a different way from MSVC/Windows:
Windows:
Main EXE and every DLL get their own static-linked C library.
Can opt into a shared DLL for the C library, but this adds wonk.
BGBCC+TestKern:
Main EXE gets a static-linked C library;
Exports a COM interface that DLLs can use;
DLLs get a static linked C-library stub;
Invokes main C library via a hidden COM interface.
This basically allows things like malloc/free and stdio to work across DLL boundaries (unlike Windows where each gets their own local heap and stdio, and trying to invoke a pointer from one DLL in another tends to cause stuff to explode).
Granted, the DLLs effectively pulling the C library from the main EXE via COM objects may seem a little unorthodox, but it seemed like the best way to address my use cases.
(I'm snipping all the details of your own C compiler, because there is very little I can comment on.)Curious...
>Agreed.>>>
>
But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.
>
I don't find C++ carries noticeably penalties compared to C, for my embedded work. But I do disable exceptions and RTTI - exceptions may have very little run-time time overhead, but the unwind tables can be significant when code size is important in small systems.
>
Yes, that is the main thing.
They carry zero performance penalty in practice;
But, have a non-zero penalty for image size.
>
Not enough to be a deal-breaker towards using them if they are used, but enough that one wants them disabled if not used...
>
(I could also note that I make heavy use of templates in C++ code - it often leads to smaller and faster results.)
I had tended to use the "write everything one off for the task at hand" approach, but this is a higher-effort approach.
...
Les messages affichés proviennent d'usenet.