Gertjan Klein wrote:
> Tim Roberts wrote
>> However, I'll bet I know what it is. CPUID trashes ebx, and in the x86
>> calling sequence, that's supposed to be saved and restored.
>>
>
> That's it! Now, both Python 2.5 and 2.6 (and 3.1, if I change the print
> statement) run this code successfu
Dave Angel wrote:
>>
> On general principle, I'd use
>push ebx
> ...
>pop ebx
>
> pairs around the cpuid instruction, if trashing ebx is a problem.
> Seems to me it's safer than making any assumptions about implicit
> saves/restores.
That's what the "uses ebx" clause that I added to th
Gertjan Klein wrote:
Tim Roberts wrote:
However, I'll bet I know what it is. CPUID trashes ebx, and in the x86
calling sequence, that's supposed to be saved and restored.
That's it! Now, both Python 2.5 and 2.6 (and 3.1, if I change the print
statement) run this code successfully. Do
Tim Roberts wrote:
>However, I'll bet I know what it is. CPUID trashes ebx, and in the x86
>calling sequence, that's supposed to be saved and restored.
That's it! Now, both Python 2.5 and 2.6 (and 3.1, if I change the print
statement) run this code successfully. Does that mean there is a
differe
Gertjan Klein wrote:
> Interestingly, if I place a ret after the mov eax, [style] instruction,
> or even comment out the cpuid instruction, I don't get an exception.
> This makes me wonder whether there is something permission-related that
> is different between Python 2.5 and 2.6 -- perhaps the 2.
Tim Roberts wrote:
>Very interesting. I tried this on Python 2.5.2 on my Windows 7 64
>system (using 32-bit Python). The C version works fine, but the
>assembler version gets a "DLL initialization error". I fixed that by
>adding "mov eax, 1" to the "start" routine. See if that helps your issue
Gertjan Klein wrote:
> Out of pure curiousity (I used to write a lot of assembler, but those
> days are long gone) I tried your code, and it works as advertised -- on
> Python 2.6. It fails on Python 2.5 with "WindowsError: exception code
> 0x20800", but oddly I've also seen error code 0x1020800. I
Tim Roberts wrote:
>In my opinion, you could have solved this all much quicker and easier
>just by writing a trivial DLL.
Out of pure curiousity (I used to write a lot of assembler, but those
days are long gone) I tried your code, and it works as advertised -- on
Python 2.6. It fails on Python 2.
Tim Roberts wrote:
> Tim Roberts wrote:
>
>> J wrote:
>>
>>
>>> On Tue, Jan 5, 2010 at 16:53, Tim Roberts wrote:
>>>
>>>
>>>
>>>
C:\tmp>python
Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] onwin32
Type "help", "copyright"
Tim Roberts wrote:
> J wrote:
>
>> On Tue, Jan 5, 2010 at 16:53, Tim Roberts wrote:
>>
>>
>>
>>> C:\tmp>python
>>> Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
>>> (Intel)] onwin32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>>
J wrote:
> On Tue, Jan 5, 2010 at 16:53, Tim Roberts wrote:
>
>
>> C:\tmp>python
>> Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
>> (Intel)] onwin32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import ctypes
>> >>> c = ctypes.windll.c
On Tue, Jan 5, 2010 at 16:53, Tim Roberts wrote:
> In my opinion, you could have solved this all much quicker and easier
> just by writing a trivial DLL.
Indeed... and I may well have tried that, were I actually capable of
reading and writing assembly and/or low-level C... Unfortunately, I'm
not
J wrote:
> I've been at this a while :)
>
> Thought I'd ask if anyone knew either of a way in python, or just a
> stand alone tool, to use in Windows to get CPU information.
> Specifically, I'm looking for Feature sets or Flags.
>
> What I'm doing is building a tool for work that gets certain bits
13 matches
Mail list logo
