Author Topic: CPUID Test piece for later Intel processors.  (Read 24124 times)

qWord

  • Member
  • *****
  • Posts: 1473
  • The base type of a type is the type itself
    • SmplMath macros
Re: CPUID Test piece for later Intel processors.
« Reply #30 on: July 07, 2012, 11:51:03 PM »
You may add some error handling code for the APIs.
Also, InitCommonControlsEx is called from a very “unusual place”.
MREAL macros - when you need floating point arithmetic while assembling!

Antariy

  • Member
  • ****
  • Posts: 551
Re: CPUID Test piece for later Intel processors.
« Reply #31 on: July 08, 2012, 12:15:45 AM »
   Still crashes.  Screen capture JPEG renamed to ZIP
is attached.

Hi, Steve!

Just wondering why it's crashing. Could you run this command in the DOS box (cmd.exe) to get some more info?
Code: [Select]
ntsd intelmmi.exe

and then, when the new DEBUG-like debugger console window will open, type in it:
Code: [Select]
g [enter]

after that the debugged program will hang (crash) and control will be passed to a debugger (a prompt like 0:000> will appear in the debugger console window), type in the debugger:
Code: [Select]
kb [enter]

Contents of the console (entire or just info that was output after "kb") is a useful info which could help to find a bug.

FORTRANS

  • Member
  • *****
  • Posts: 1077
Re: CPUID Test piece for later Intel processors.
« Reply #32 on: July 08, 2012, 10:51:21 PM »
   Still crashes.  Screen capture JPEG renamed to ZIP
is attached.

Hi, Steve!

Just wondering why it's crashing. Could you run this command in the DOS box (cmd.exe) to get some more info?
Code: [Select]
ntsd intelmmi.exe

Hi Antariy

   Okay, will do.

Quote
and then, when the new DEBUG-like debugger console window will open, type in it:
Code: [Select]
g [enter]

after that the debugged program will hang (crash) and control will be passed to a debugger (a prompt like 0:000> will appear in the debugger console window), type in the debugger:
Code: [Select]
kb [enter]

Contents of the console (entire or just info that was output after "kb") is a useful info which could help to find a bug.

   Well, here it is.


Microsoft(R) Windows 2000 Debugger
Version 5.00.2184.1
Copyright (C) Microsoft Corp. 1981-1999

CommandLine: intelmmi.exe
Symbol search path is: C:\WINNT
NTSD ModLoad: 00400000 0040a000   image00400000
NTSD ModLoad: 77f80000 77ffc000   ntdll.dll
NTSD ModLoad: 77e10000 77e6f000   C:\WINNT\system32\user32.dll
NTSD ModLoad: 7c570000 7c624000   C:\WINNT\system32\KERNEL32.dll
NTSD ModLoad: 77f40000 77f7d000   C:\WINNT\system32\GDI32.dll
NTSD ModLoad: 71710000 71794000   C:\WINNT\system32\comctl32.dll
NTSD ModLoad: 7c2d0000 7c335000   C:\WINNT\system32\ADVAPI32.dll
NTSD ModLoad: 77d30000 77d9f000   C:\WINNT\system32\RPCRT4.dll
eax=00000000 ebx=00131f04 ecx=00000009 edx=00000000 esi=7ffdf000 edi=00131f78
eip=77f9193c esp=0012f984 ebp=0012fc98 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
77f9193c cc               int     3
0:000> g
NTSD: access violation
eax=00495030 ebx=00000000 ecx=0005014c edx=00470650 esi=00000000 edi=00000111
eip=77e28ce8 esp=0012fde8 ebp=0012fe08 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00210206
user32!CharPrevW+408:
77e28ce8 f6432bc0         test   byte ptr [ebx+0x2b],0xc0 ds:0023:0000002b=??
0:000> kb
*** ERROR: Module load completed but symbols could not be loaded for image004000
00
ChildEBP RetAddr  Args to Child
0012fe08 77e2d428 0005014c 00000111 000003e8 user32!CharPrevW+0x408
0012fe40 77e14605 77e2d407 0005014c 00000111 user32!DefDlgProcA+0x21
0012fecc 77e1a7f2 0012ff18 00000000 77e2ecf3 user32!TranslateMessageEx+0x605
0012fefc 77e33568 0005014c 00495030 00000000 user32!DispatchMessageW+0xb
0012ff38 77e44327 0005014c 00000000 00000010 user32!MessageBoxA+0x1b5
0012ff5c 77e38d37 00400000 004092f8 00000000 user32!CheckRadioButton+0x13d
0012ff7c 77e3ede7 00400000 004092f8 00000000 user32!DialogBoxIndirectParamAorW+0
x34
0012ffa8 00401025 00400000 000003e8 00000000 user32!DialogBoxParamA+0x4a
0012fff0 00000000 00401000 00000000 000000c8 image00400000+0x1025
0:000>


   Hope that helps.

Regards,

Steve N.

Antariy

  • Member
  • ****
  • Posts: 551
Re: CPUID Test piece for later Intel processors.
« Reply #33 on: July 09, 2012, 09:02:37 AM »

Hi Antariy

   Okay, will do.

...

   Hope that helps.


Hi, Steve!

Yes, it have helped, thank you very much!

The bug (edited: to make it clear - it is not mine, as well as the program) is in get_cpu_id_string function. It doesn't preserve EBX before CPUID instructions at start of function.
« Last Edit: July 10, 2012, 09:43:21 AM by Antariy »

Antariy

  • Member
  • ****
  • Posts: 551
Re: CPUID Test piece for later Intel processors.
« Reply #34 on: July 10, 2012, 07:40:34 AM »
Here is some incredible code. It just requires to copy and paste the source below directly into the console (on 32 bit OSes, x64 do not support 16 bit apps) to compile. Then type ATXT and this cool advanced CPUID proggie will run :biggrin:

Code: [Select]
debug
a
mov dx,11C
mov ah,9
int 21
push sp
pop ax
cmp ax,sp
mov dx,191
jz 112
mov dl,79
mov ah,9
int 21
xor ax,ax
int 16
ret
db 0D,0A,0D,0A,09,09,09,"The advanced CPU Identification program"
db 0D,0A,09,09,09,09,"   (c) Antariy 2012",0D,0A,0D,0A
db 09,09,09,"Here we have a $"
db "Tyrannosaurus reX86 CPU$"
db "Some modern 80286+ stuff$"

r cx
AA
n ATXT.com
w
q

dedndave

  • Member
  • *****
  • Posts: 8827
  • Still using Abacus 2.0
    • DednDave
Re: CPUID Test piece for later Intel processors.
« Reply #35 on: July 10, 2012, 08:49:42 AM »
yes - i seem to recall that some earlier processors altered SP before the PUSH instead of after

Antariy

  • Member
  • ****
  • Posts: 551
Re: CPUID Test piece for later Intel processors.
« Reply #36 on: July 10, 2012, 09:13:51 AM »
yes - i seem to recall that some earlier processors altered SP before the PUSH instead of after

:biggrin: :t

CodeDog

  • Guest
Re: CPUID Test piece for later Intel processors.
« Reply #37 on: October 12, 2012, 01:17:20 AM »
I have one to check ht support and core count, but is fasm. The only significant difference between fasm and masm is the use of brackets, so its not much difference.


Code: [Select]
; checks if HTT is supported on the cpu
; returns 0 in eax if not supported and 1 otherwise
proc HTSupport
xor eax,eax
cpuid
; check that functions 0-1 is at least supported as these are the ones we will use
cmp eax,1
jb .fail
; check that GenuineIntel, because intel is the only one that have hyper threading
cmp ebx,$756e6547 ; Genu
jne .fail
cmp edx,$49656e69 ; ineI
jne .fail
cmp ecx,$6c65746e ; ntel
jne .fail
; Now get HT flag in edx at bit 28 (zero based)
mov eax,1
cpuid
test edx,$10000000
jnz .succ
.fail: xor eax,eax
ret
.succ: mov eax,1
.bye: ret
endp

; Return the accurate number of cores (HT is checked too)
proc CoreCount
local ht rd 1
local s SYSTEM_INFO
      stdcall HTSupport
      mov [ht],eax
      lea eax,[s]
      invoke GetSystemInfo,eax
      mov eax,[s.dwNumberOfProcessors]
      mov ecx,[ht]
      test ecx,ecx
      jz @F
      shr eax,1
@@:   ret
endp