Python update trouble (2.3 to 2.4): x<<y
sjmachin at lexicon.net
Sun May 21 23:43:57 CEST 2006
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?
More information about the Python-list