5 ms·

I once has to rewrite legacy firmware where the original author didn’t believe in .c files. You can still compile with only header files (but only if it’s all h

by m-ee 6y ago

I once has to rewrite legacy firmware where the original author didn’t believe in .c files. You can still compile with only header files (but only if it’s all headers, no mixing what he did with normal structure), but I still wonder why he thought that was a good idea. He works for Facebook now.

deleted 6y ago
[deleted]
542458 6y ago
That is a legitimate strategy for libraries so you don’t have to package everything. Not sure why why you’d do it for firmware though. https://en.m.wikipedia.org/wiki/Header-only https://en.m.wikipedia.org/wiki/Header-only Maybe the author was cargo-culting that?
- avian 6y ago
  Often having everything in one compilation unit results in a smaller and/or faster binary. I’ve seen this happen even when using LTO. It’s a common practice when developing firmware for small micros.
  - ReactiveJelly 6y ago
    At work I do amalgamation builds where I `#include` 10s of files into 4 .cpp files so I can do `make -j 4` and end up with 4 compilation units. It's stupid. It messes up `using`. It doesn't do incremental rebuilds. But it does clean builds fast for the release script, and it saves me from setting up cross-compilation on a faster computer.
    - sfink 6y ago
      It's not just stupid, it breaks the language. Things will be valid when compiled together that are invalid C++ when compiled separately. Your #includes will become more and more wrong over time, and if you ever change the grouping of files all kinds of random unrelated stuff will break. It's also a really great idea, for the reasons you give. This is how the Firefox tree is built, and it gives massive compile and link time speedups. (We call it "unified builds".) Some runtime speedups too. I guess that's from better cross-file inlining?
      - saagarjha 6y ago
        WebKit does it too, and there’s a certain style you need to write your code in for it to work. (Generally, namespace everything.)
  - zb 6y ago
    I recall encountering compilers that required this - there was no linker essentially. Sometimes that was all you had available. Most of the manufacturers eventually just wrote gcc backends for their architectures, but the era of crappy proprietary compilers went on far too long in many cases.
    - m-ee 6y ago
      Microchip XC16, broken in a few places but functional and definitely allowed for .c files.
  - m-ee 6y ago
    It wasn’t a small micro (16 bit dspic) and the code was far from fast. I think it was just cargo culting. He also removed all floats because “integer math is faster” but never tested it. Put floats back in and sped things up a couple orders of magnitude. Another highlight, no main loop. Everything was in an interrupt. This allowed the code to run despite a very broken i2c driver because it was given a low enough priority that other tasks could preempt it while it was hanging indefinitely.
- cheese65536 6y ago
  A lot of embedded compilers are bad or at least old. You frequently only get C and not C++, so you can use header files as a sort of template. Write all your real code to use a peripheral in the header, but wrap all the function names, global variable names, and peripheral register names in special macros. Then, in the .c file, you can include the header file multiple times as long as before each include you define a handful of macros that rename all the function, global variable, and register names in the header so they refer to the correct peripheral instance.

by m-ee 6y ago

deleted 6y ago

[deleted]

542458 6y ago

That is a legitimate strategy for libraries so you don’t have to package everything. Not sure why why you’d do it for firmware though. https://en.m.wikipedia.org/wiki/Header-only https://en.m.wikipedia.org/wiki/Header-only Maybe the author was cargo-culting that?

avian 6y ago
Often having everything in one compilation unit results in a smaller and/or faster binary. I’ve seen this happen even when using LTO. It’s a common practice when developing firmware for small micros.
- ReactiveJelly 6y ago
  At work I do amalgamation builds where I `#include` 10s of files into 4 .cpp files so I can do `make -j 4` and end up with 4 compilation units. It's stupid. It messes up `using`. It doesn't do incremental rebuilds. But it does clean builds fast for the release script, and it saves me from setting up cross-compilation on a faster computer.
  - sfink 6y ago
    It's not just stupid, it breaks the language. Things will be valid when compiled together that are invalid C++ when compiled separately. Your #includes will become more and more wrong over time, and if you ever change the grouping of files all kinds of random unrelated stuff will break. It's also a really great idea, for the reasons you give. This is how the Firefox tree is built, and it gives massive compile and link time speedups. (We call it "unified builds".) Some runtime speedups too. I guess that's from better cross-file inlining?
    - saagarjha 6y ago
      WebKit does it too, and there’s a certain style you need to write your code in for it to work. (Generally, namespace everything.)
- zb 6y ago
  I recall encountering compilers that required this - there was no linker essentially. Sometimes that was all you had available. Most of the manufacturers eventually just wrote gcc backends for their architectures, but the era of crappy proprietary compilers went on far too long in many cases.
  - m-ee 6y ago
    Microchip XC16, broken in a few places but functional and definitely allowed for .c files.
- m-ee 6y ago
  It wasn’t a small micro (16 bit dspic) and the code was far from fast. I think it was just cargo culting. He also removed all floats because “integer math is faster” but never tested it. Put floats back in and sped things up a couple orders of magnitude. Another highlight, no main loop. Everything was in an interrupt. This allowed the code to run despite a very broken i2c driver because it was given a low enough priority that other tasks could preempt it while it was hanging indefinitely.
cheese65536 6y ago
A lot of embedded compilers are bad or at least old. You frequently only get C and not C++, so you can use header files as a sort of template. Write all your real code to use a peripheral in the header, but wrap all the function names, global variable names, and peripheral register names in special macros. Then, in the .c file, you can include the header file multiple times as long as before each include you define a handful of macros that rename all the function, global variable, and register names in the header so they refer to the correct peripheral instance.