Python update trouble (2.3 to 2.4): x<<y

[John Machin]

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