Showing posts with label C. Show all posts
Showing posts with label C. Show all posts

2016-03-26

An IS_DEFINED() C macro to check whether another macro is defined

Every C programmer knows to use #defines and #ifdefs to disable compilation for a piece of code. But not everyone knows that there are better ways; the problem with this strategy is that the code becomes invisible to the compiler (and "smart" indexers), which means that it stops being checked for correctness. Also, if the rest of the code changes substantially, like variable renaming, function changing their signatures, etc, the disabled part falls out of sync and will need possibly serious work when re-enabled.

There are easy improvements to the #ifdef strategy, with the inconvenience that they add boilerplate and/or waste cycles on runtime (important on embedded environments). But there's also a way to remove both the boilerplate AND the runtime checks!

2015-07-30

My first official Linux kernel patch

Well, that took some time. Quite an exacting process… which makes you get a new perspective of how Linux is made, and what it takes to keep loose collaboration at a high quality level.

And interesting too how such a simple patch evolved. First it made me think of the bike shed

2015-07-21

6 tips to survive Codility tests

Well, it happened. When applying for a job, I got sent to a Codility test. And even though I guess I already had some good practice with them, I managed to do badly in stupid ways – ways that 2 years ago I had already thought about and even taken notes on. Just, in the heat of the moment I forgot about those rules of thumb.

And in fact I think these hints should be given by Codility themselves – because if not you are practically ambushed, even more so if you didn't take the time to thoroughly explore how they work. So here are my hints-to-self.

The summary is: don't think of this as a coding interview; this is rather about getting something working, ASAP.

2015-06-25

Eclipse CDT configuration for big, makefile-based projects

It's been kinda hard to get Eclipse to work well with big CDT projects (say, the Linux kernel, or even a BuildRoot project including the Linux kernel). The documentation for Eclipse is between non-existent and unhelpful, and I only could find a post that talked specifically about preparing an Eclipse project for the Linux kernel. But that post explains nothing, and does some arbitrary things. So this is the generalization of that.

2013-09-13

Type punning, aliasing, unions, strict-aliasing, oh my!

Imagine that you have a struct s which sometimes needs to be volatile (because it maps to a set of hardware registers) but other times you'd rather have it non-volatile (because you are working on a bunch of such structs that have been stored, so they are no longer used to interface to the hardware and you could do without the performance penalty of volatile).

That is easy enough: you can have your variables declared volatile or not depending on the situation.

But what happens when you have a function to deal with those structs? Could it be implemented so it not only works, but does the right thing in both volatile and non-volatile structs?

The trivial way to have such a thing is by just defining 2 versions of the function (with different names of course) with the differently qualified parameters; but another possibility is to define a union type in which one member is the plain type and the other is the volatile-qualified type, and make the function parameters use that union type. Standard-wise, it should work… shouldn't it?

2013-02-25

Taking a snapshot of the ports in an AVR (AT90CAN128)

A small inline function to take a snapshot of all the ports as simultaneously as possible, which means 7 cycles from first to last, which means less than 0.5 usec from first to last at 16 MHz. Can't be faster.

Had to be done in asm inline because if not gcc prefers to interleave the input instructions with store instructions. Done this way, the inputs come first and the storage comes later, generated automatically.

2012-07-06

Memory access stride in loops change loop timing in AVR C!

I found a strange situation when programming in C for AVRs. I have a bunch of structures to be worked on, but any of them can be flagged "active" or not at any given moment, to signal whether they need further work. My first approximation was to add a (uint8_t volatile: set in main, checked in interrupt time) member variable named "active" to the struct, to quickly check/set each structure.

Shock: only looping through the array checking the "active" member variables was taking an enormous amount of time – about 20 clock cycles per access!