On Tue, 28 Aug 2007, Manu Abraham wrote: > * use integer math calculations > * precompute the values where double precision is needed. > > That said, the first option i tried for a while, after a few days (i > almost gave up ?) got really irritated with it. > The second option seemed a bit more comfortable, to precalculate the values. > > The disadvantage in such a case is that the array which holds the > precomputed value is quite large in size, with that in mind, a different > question arose in my mind, whether such large arrays would be frowned > upon in kernel > > The precomputed array is here > > http://www.jusst.de/manu/mc44s80x_array.c > > Any thoughts ? That's really inefficient. You've got about 250k of table there. I don't think a 250k+ module is going to be very popular. The table could be packed a lot better. None of the fields need to be 64-bit, so don't use unsigned long which is 64 bits on 64 bit platforms. Most of those fields don't even have 32 bits that change. For example, I can see that the last 12-bits of the refdiv field are always 0x9b2. You could put that field in 8-bits (or less, it looks like only 5 bits change). The freq field looks like it's just every 1/6th MHz from 50 Mhz to 1 GHz. Why do you need to store that? It should be trivial to calculate. unsigned int x; /* must be unsigned! Good to x=8589 1.4815 GHz*/ tuner_step_166k[x].freq = (x * 500000 + 1)/3 + 50000000; Or the other way around, table index from frequency: unsigned int freq, x; x = ((freq - 50000000) * 3 + 250000) / 500000; _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
