5 ms·

Playing the devil's advocate, here. When possible, this kind of if_arch/else should be compartmentalized in their own object files or dynamic libraries, and the

by mackwic 12y ago

Playing the devil's advocate, here. When possible, this kind of if_arch/else should be compartmentalized in their own object files or dynamic libraries, and then, linked conditionally to produce an unique binary. You shouldn't clutter your code with ifdef. It makes it hard to think with.

SixSigma 12y ago
The whole of Plan9 is written like that. If you look here http://plan9.bell-labs.com/sources/plan9/sys/src/9/ http://plan9.bell-labs.com/sources/plan9/sys/src/9/ You can see that port & boot are the portable code. Each architecture can fall back on that less optimised code should it need to. Then each of the directories: bcm, kw, mtx, omap, pc, pcboot, ppc, rb, teg have platform specific c files This greatly eases porting to a new architecture and also means cross compilation is significantly easier. #ifdefs are rare in the source code and other pragmas are few and far between. Conditional compilation is the enemy of readable code.
- sitkack 12y ago
  Moving and re-moving conditionals is our life. Is there a name for that structure? Polymorphic portability.
linuxlizard 12y ago
While I dislike #if/#else/#endif, dynamic libraries rarely exist in embedded systems. Using many small object files is my solution of choice but it pushes the if/else/endif problem into the Makefile instead.
- mackwic 12y ago
  I personally tend to use yaml files which contains matrices of compatibility between objects, used to generate CMake statements. I know people who use the file header to autodetect the right architecture but I found it too overkill and weird-bug-prone.
vonmoltke 12y ago
The "when possible" in your statement is a caveat large enough to drive a semi through. Professionally I have only done "big" embedded, but I have for example had a rather lengthy signal processing algorithm where sections needed to be implemented one way for most POWER systems and another way for x86-64 systems. The wrong branch cratered performance[1]. There was no way to separate the code the way you describe without implementing it twice. [1] At the risk of starting a flame war, this situation and those like it have really soured me on the rest of the industry's obsession with "big O" for complexity analysis. I have never found it useful; I always needed to pay attention to the stuff I was supposed to be dropping.
- mackwic 12y ago
  > The "when possible" in your statement is a caveat large enough to drive a semi through You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow. > There was no way to separate the code the way you describe without implementing it twice. Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world...
  - vonmoltke 12y ago
    > You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow. Well, the architecture of what I was working on was not going to win any awards. :P It was made worse because we were converting code that was originally implemented to run on DSPs. > Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world... Standard practice was for systems engineers[1] to create Algorithm Description Documents and Algorithm Implementation Documents that explained in mathematical formulas (ADD) and pseudocode (AID) what the code was doing. At least. that was the theoretical practice. The actual practice was a mess. But yes, there is no silver bullet. [1] Which was me, even though I got to write lots of code, too.
com2kid 12y ago
I actually agree, none of my code has #IFDEF, except at the top of the C file that decides if that C file will be built or not. (This simplifies having different C files per platform in the build system, adding new projects in our system is complicated enough as is! Right now it just builds .c, .cpp in every directory)

by mackwic 12y ago

SixSigma 12y ago

The whole of Plan9 is written like that. If you look here http://plan9.bell-labs.com/sources/plan9/sys/src/9/ http://plan9.bell-labs.com/sources/plan9/sys/src/9/ You can see that port & boot are the portable code. Each architecture can fall back on that less optimised code should it need to. Then each of the directories: bcm, kw, mtx, omap, pc, pcboot, ppc, rb, teg have platform specific c files This greatly eases porting to a new architecture and also means cross compilation is significantly easier. #ifdefs are rare in the source code and other pragmas are few and far between. Conditional compilation is the enemy of readable code.

sitkack 12y ago
Moving and re-moving conditionals is our life. Is there a name for that structure? Polymorphic portability.

linuxlizard 12y ago

While I dislike #if/#else/#endif, dynamic libraries rarely exist in embedded systems. Using many small object files is my solution of choice but it pushes the if/else/endif problem into the Makefile instead.

mackwic 12y ago
I personally tend to use yaml files which contains matrices of compatibility between objects, used to generate CMake statements. I know people who use the file header to autodetect the right architecture but I found it too overkill and weird-bug-prone.

vonmoltke 12y ago

The "when possible" in your statement is a caveat large enough to drive a semi through. Professionally I have only done "big" embedded, but I have for example had a rather lengthy signal processing algorithm where sections needed to be implemented one way for most POWER systems and another way for x86-64 systems. The wrong branch cratered performance[1]. There was no way to separate the code the way you describe without implementing it twice. [1] At the risk of starting a flame war, this situation and those like it have really soured me on the rest of the industry's obsession with "big O" for complexity analysis. I have never found it useful; I always needed to pay attention to the stuff I was supposed to be dropping.

mackwic 12y ago
> The "when possible" in your statement is a caveat large enough to drive a semi through You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow. > There was no way to separate the code the way you describe without implementing it twice. Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world...
- vonmoltke 12y ago
  > You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow. Well, the architecture of what I was working on was not going to win any awards. :P It was made worse because we were converting code that was originally implemented to run on DSPs. > Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much. That's not always the best solution, thought. There's no silver bullet in this world... Standard practice was for systems engineers[1] to create Algorithm Description Documents and Algorithm Implementation Documents that explained in mathematical formulas (ADD) and pseudocode (AID) what the code was doing. At least. that was the theoretical practice. The actual practice was a mess. But yes, there is no silver bullet. [1] Which was me, even though I got to write lots of code, too.

com2kid 12y ago

I actually agree, none of my code has #IFDEF, except at the top of the C file that decides if that C file will be built or not. (This simplifies having different C files per platform in the build system, adding new projects in our system is complicated enough as is! Right now it just builds .c, .cpp in every directory)