On 1/13/06, Patrick Boettcher <patrick.boettcher@xxxxxxx> wrote: > Hi, > > I know this will be slightly off-topic, but at least it is related to > linux-dvb as linux-dvb drivers will be the result: > > For our demodulators some reception-sensitive values are different for > each application (devices/systems). Clever heads are calculating those > values while doing exhaustive tests. By default those values are > non-decimal. As we all know, float calculations are not allowed at kernel > level, that's why the values are rounded all the time before making it > into the driver. > > My question is: Is it save to assume, that all compilers calculate the > following assignment at compile time? > > int value = 0.523 * 65535; > > Presuming it is true, would kernel guys accept such a thing: using > floats for compile time constants? > > Thanks in advance for any advice, Patrick- The above assignment doesnt work, because you are trying to assign the value, 34274.805 to an int. OTOH: int value = 1000 * 0.523 * 65535; ...and then later on when you are actually using, 'value' to use 'value / 1000' instead... This WOULD work, although it looks ugly, but it seems this is the only workaround to the no floats in kernel rule. It may be helpful for you to check out the analog simple tuner definitions located in tuner-types.c ... (this is a new file in recent cvs, older kernels have this all stored inside tuner-simple.c) and the set_freq functions at the bottom of tuner-simple.c I am currently working on the v4l tuner code to allow it to store multiple video standard parameters for each tuner-type, which eventually lead to the ability for the same tuner module to handle dvb stuff, but that is irrelevant to your question. Back to the point... In the analog tuners, you can see that each frequency limit is multiplied by 16 at compile time, which is later dealt with at run-time by dividing again. I think that a similar method would work for what you're trying to do. I hope this helps, -Mike
