On 22/05/2006 5:22 AM, Gonzalo Monzón wrote: > Thank you for all the suggestions! :-) > > The C routine is almost -changing data type long for word- a copy of the > function given by a hardware manufacturer, the same code used in their > firmware to calc the checksum of every piece of data sent or received, > and that data is somewhat special: it does not contain only plain ascii > character data (only 0x01 - 0x09 as delimiters) and every data set ends > with a 0x00 null byte so its fine to calculating checksum until "\x00" > is reached. And I must get the same crc calculations. That C routine > (and a very similar PHP one too) are tested for months and work smoothly. > > And of course I should use integer not long!!... we aren't anymore in > the 8 bit computer era... ;-) original code from hardware manufacturer > use words by the way. And now really don't know why I used long. I > thought I did that way 'cause see pyrex C generated glue code always > using PyInt_FromLong so thought would use the same type.
Perhaps we need some amplification of "of course I should use integer not long" :-) Is the transmitted checksum (which your routine must create and/or verify) 2 bytes long or 4 bytes long??? This is the most important thing; once that is established, then you choose the C and/or Python types and the mask (0xFFFF or 0xFFFFFFFF) as/if necessary. In that original specification from the manufacturer, how wide was a "word"? Note that in most/many C compilers at the moment, "int" and "long" *both* mean 32 bits, to get 64 bits you need "long long" [or "_int64" or whatever in realms under the sway of the dark tower], and "short" may get you 16 bits if you are lucky. In a typical Python environment at the moment, "int" uses the C "long", and thus typically will be 32 bits. Python "long" is a variable-length data type. Also note that even if the "checksum" is 32 bits wide, the high-order 16 bits are not verifiably useful, so you could use a [faster] 16-bit version when receiving. > > I changed the C function to use integer, and it is performing a little > bit slowly than using longs (best with long: 0.614us, best with int: > 0.629us), that is maybe as I said due pyrex glueing always the return > values with PyObject* PyInt_FromLong for all kind of short int to long > data types? Anyway both results are fine, and the timming gap is > insignificant (int: 1580403 loops -> 0.973 secs, long: 1601902 loops -> > 1.01 secs) as i usually never have to call more than 100,000 times when > loading a full file data backup. I'm somewhat puzzled: Do you have the facility to cross-compile C to run on the Pocket PC? If NO, why do you continue to mention fast versions coded in C and glued with Pyrex? If YES, why did you include a Python version in your initial question? Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
