I've attached the file instrset32.zip. It contains the sources and running applications for 32 bit Windows and Linux. An appropriate test program is included, too. The procedure detrects the instruction sets up to AVX2 properly. You may check the following threads, too: http://masm32.com/board/index.php?topic=1380.0 (http://masm32.com/board/index.php?topic=1380.0) and http://masm32.com/board/index.php?topic=1405.0 (http://masm32.com/board/index.php?topic=1405.0).
The assembly language part is written for jWasm, but it should work for masm, too. The C-source is compiled with gcc, but it should work with any other C compiler. Here is the output under Windows XP, SP3 as VM (Windows XP Mode).
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3, SSE4.1,
POPCNT, SSE4.2
featurenumber = 13
XP doesn't support AVX; I'm not sure about the behaviour under Windows 7 (32 bit). Could anyone test that, please?
The 16 bit version is much more tricky and will be published probably as stand alone assembly language application inside the 16 bit forum.
Gunther
Output when run on Win 7 Pro 32 bit version
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3
featurenumber = 10
P4 prescott w/htt
MMX, CMOV and FCOMI, SSE, SSE2, SSE3
featurenumber = 9
it looks correct, although i don't know how to interpret the featurenumber
Hi Gunther,
Works fine on my dev Core2 Quad.
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3, SSE4.1
featurenumber = 11
Thank you Steve and Andy for testing. Dave, the featurenumber is only for information. Please have a look into the C-source cpufeatures.c; that should give you enough explanation (a simple select case statement).
Gunther
good work :t
it's nice to know how to test for AVX when i don't have a machine to test it :biggrin:
Quote from: Gunther on February 03, 2013, 10:40:39 AM
Thank you Steve and Andy for testing.
Gunther
Glad to help. I like your thorough notes about what each step does.
Have you thought about seeing if Microsoft would buy a license for it ? :t
They really need help with identifying important things, o.s.'s in particular. :biggrin:
Andy
identifying the os version is WAY easier than identifying the CPU :P
http://www.masmforum.com/board/index.php?topic=11963.0 (http://www.masmforum.com/board/index.php?topic=11963.0)
i can upload the attachment if you like
these registry values....
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion]
"Version"="Windows 95"
"VersionNumber"="4.00.1111"
"ProductName"="Microsoft Windows 95"
"CurrentVersion"=(Value not found)
"CurrentBuildNumber"=(Value not found)
"SubVersionNumber"=" B"
"CSDVersion"=(Value not found)
"BuildLab"=(Value not found)
"ProductId"="24264-XXX-XXXXXXX-XXXXX"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center]
"Ident"=(Key not found)
OSVERSIONINFOEX Structure:
Version.Build: 4.0.67109975
Platform ID: Win32 on Windows 95
CSD Version: B
and the stuff at the end is from GetVersionEx
Quote
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3
featurenumber = 10
Windows 7/64 bit ultimate - Core Duo INTEL
Hi Dave,
Quote from: dedndave on February 03, 2013, 12:54:00 PM
identifying the os version is WAY easier than identifying the CPU :P
http://www.masmforum.com/board/index.php?topic=11963.0 (http://www.masmforum.com/board/index.php?topic=11963.0)
i can upload the attachment if you like
why not. But it's not the question of detecting the underlying operating system. We have to check if the operating system is at least SSE aware, because the xmm registers must be saved during task switches. Unfortunately, the information that can be obtained from the CPUID instruction is not sufficient for determining whether it is possible to use XMM registers. The CPU can disable the use of the XMM registers in order to prevent their use under old operating systems that do not save these registers. Operating systems that support the use of XMM registers must set bit 9 of the control register CR4 to enable the use of XMM registers and indicate its ability to save and restore these registers during task switches.
Unfortunately, the CR4 register can only be read in privileged mode. Application programs therefore have a serious problem determining whether they are allowed to use the XMM registers or not. According to official Intel documents, the only way for an application program to determine whether the operating system supports the use of XMM registers is to try to execute an XMM instruction and see if you get an invalid opcode exception. But not all operating systems, compilers and programming languages provide facilities for application programs to catch invalid opcode exceptions. A Windows application, for example, using Intel's detection method would therefore have to be tested in all compatible operating systems, including various Windows emulators running under a number of other operating systems.
The demonstrated detection method in the procedure doesn't have this drawback. That is the point.
Gunther
Hi Andy,
Quote from: Magnum on February 03, 2013, 12:09:07 PM
Have you thought about seeing if Microsoft would buy a license for it ? :t
no, not really. But we should help other code writers which are relatively new to assembly language. Therefore the comments and remarks.
Gunther
QuoteUnfortunately, the CR4 register can only be read in privileged mode. Application programs therefore have a serious problem determining whether they are allowed to use the XMM registers or not. According to official Intel documents, the only way for an application program to determine whether the operating system supports the use of XMM registers is to try to execute an XMM instruction and see if you get an invalid opcode exception. But not all operating systems, compilers and programming languages provide facilities for application programs to catch invalid opcode exceptions. A Windows application, for example, using Intel's detection method would therefore have to be tested in all compatible operating systems, including various Windows emulators running under a number of other operating systems.
The demonstrated detection method in the procedure doesn't have this drawback. That is the point.
i see - very interesting :t
however, i think if you tested XP, Vista, Windows 7, you'd have enough info to determine support level
Hi Dave,
Quote from: dedndave on February 03, 2013, 10:57:31 PM
i see - very interesting :t
however, i think if you tested XP, Vista, Windows 7, you'd have enough info to determine support level
that might be. I'll tell you the following story. My son (20 years old) has a Linux (64 bit) installed and he experimented with Wine (the Windows emulator). He needs a special Wine version for some older software to run. What about that? That's the next serious problem.
Gunther
well - that could be a number of things
but - i hadn't considered os's other than windows, really
at my age, i have more than i can handle learning xp, vista, and win7 - lol
Quote from: Gunther on February 03, 2013, 09:45:17 PM
Hi Andy,
Quote from: Magnum on February 03, 2013, 12:09:07 PM
Have you thought about seeing if Microsoft would buy a license for it ? :t
no, not really. But we should help other code writers which are relatively new to assembly language. Therefore the comments and remarks.
Gunther
The comment was meant as humor.
I should have labeled the comment at the end.
Andy
Hi,
P-III, Win 2000. P-MMX, Win 98. Celeron, Win XP.
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE
featurenumber = 7
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX
featurenumber = 5
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2
featurenumber = 8
Cheers,
Steve
Hi Andy,
I know, I know. It was a joke.
Gunther
Hi Fortrans,
thank you for testing. Interesting enough: Windows 98 is XMM aware.
Gunther
Hi Dave,
Quote from: dedndave on February 03, 2013, 11:26:27 PM
well - that could be a number of things
but - i hadn't considered os's other than windows, really
at my age, i have more than i can handle learning xp, vista, and win7 - lol
yes, we've not much influence in which environment our well written software is running. Since the advent of the virtual machines - VMware, VirtualBox and the like - the environment can be very exotic. We've to live with that.
Gunther
I downloaded Boch's but it was way too involved setting up.
I tried Sanboxie, but whenever I told it to run something outside the box, it kept asking to run it in a box.
I got to do some Super Bowl preparations.
Hi Gunther,
Well that laptop was sold with Win 95 (or OS/2 Warp).
So Win 98 being MMX aware is not too surprising. Or is
it?
Regards,
Steve N.
i have a win 98 machine
i think it's somewhat like yours, Steve
it has a Pentium III MMX
MMX happened about the same time as windows 98, maybe a little before
win 95, 98, and ME may have executed whatever your CPU had :P
the "illegal instruction" was caught by the CPU - not the OS
i don't recall any way to disable instructions or instruction sets on the older cores
Hi Fortrans,
Quote from: FORTRANS on February 05, 2013, 12:14:44 AM
Well that laptop was sold with Win 95 (or OS/2 Warp).
So Win 98 being MMX aware is not too surprising. Or is
it?
no, it isn't surprising. MMX was introduced 1997.
Dave,
Quote from: dedndave on February 05, 2013, 01:29:00 AM
i don't recall any way to disable instructions or instruction sets on the older cores
I think there isn't a way to disable instruction sets on the older cores. The only way is, to check what's supported and call the right library (if available). Intel calls that technique CPU dispatching.
Gunther
Under the first post of this thread is now the archive Iset32U1.zip. It's a major update of the instruction detection procedure. Please, have a look into that thread (http://masm32.com/board/index.php?topic=1405.msg32549#msg32549), too. Both programs have the same logic, because they are interwoven.
The C sources are compiled with gcc, but VS or Pelle's C should also work, but that must be tested. The assembly language source is for jWasm/ml. For a more detailed description of the source files, please have a look into the readme.txt file.
Here is the output under Windows 7 (64 bit):
Quote
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-3770CPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Please, press enter to end the application ...
Here with the same machine, but with Windows XP Mode under VirtualPC:
Quote
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-3770CPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Please, press enter to end the application ...
The little difference comes from the point, that XP doesn't support AVX and subsequent instruction sets. Here's the output from my old AMD box running a native XP with SP3:
Quote
Supported Features by Processor and Operating System
====================================================
Vendor String: AuthenticAMD
Brand String: AMDAthlon(tm)64X2Dual-CoreProcessorTK-57
Instruction Sets
----------------
MMX SSE SSE2 SSE3
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Please, press enter to end the application ...
Your help and test results are very welcome.
Gunther
Results with Windows 8.1 64 bit
QuoteSupported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-4930KCPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Marinus
Hi Gunther,
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3, SSE4.1
featurenumber = 11
This is correct on my old Core2 quad.
SuperDave,
I am probably as old as you, and that is a compliment. :-)
You have an older system, but I would recommend Puppy LInux.
Hi Marinus,
thank you for testing the application. I think your CPU is a later Ivy Bridge, isn't it?
Gunther
Steve,
Quote from: hutch-- on April 27, 2014, 02:53:31 PM
Hi Gunther,
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3, SSE4.1
featurenumber = 11
This is correct on my old Core2 quad.
okay, but that's the old archive. The update is in Iset32U1.zip.
Gunther
Hi
Microsoft Windows [Version 6.3.9600] = Win 8.1 64 bit with an Haswell CPU
Supported by Processor and installed Operating System:
------------------------------------------------------
MMX, CMOV and FCOMI, SSE, SSE2, SSE3, SSSE3, SSE4.1,
POPCNT, SSE4.2
featurenumber = 13
Regards, Biterider
Hi Gunther,
Same systems as in Reply #15 for comparison.
P-III, Win 2000. P-MMX, Win 98. Celeron, Win XP.
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Not supported.
Instruction Sets
----------------
MMX SSE
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Please, press enter to end the application ...
This program has performed an illegal operation
and will be shut down.
If the problem persists, contact the program
vendor.
CPU executed an invalid instruction in
module CPU.EXE at 0167:0040131a.
Registers:
EAX=8156b278 CS=0167 EIP=0040131a EFLGS=00010212
EBX=00000001 SS=016f ESP=0074fd80 EBP=0074fe38
ECX=00000000 DS=016f ESI=bff92d08 FS=0e3f
EDX=00000041 ES=016f EDI=0074fe20 GS=0000
Bytes at CS:EIP:
0f 44 cb eb e8 90 84 d2 74 0b 83 c0 01 0f b6 10
Stack dump:
78000000 00409000 00000000 0000001f cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc 0000001b 001f0010 001f03ca 0074ff78
(The stack dump was wrapped in the dialog.)
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: MobileIntel(R)Celeron(R)processor600MHz
Instruction Sets
----------------
MMX SSE SSE2
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Please, press enter to end the application ...
HTH,
Steve N.
Here is the later one on my old quad.
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)2QuadCPUQ9650@3.00GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
Please, press enter to end the application ...
i didn't notice SAHF/LAHF on any of the other processors, which i think they should support
although it applies to 64-bit mode, it's nice to know if the feature is present, even in 32-bit
this is my prescott - all seems correct :t
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Pentium(R)4CPU3.00GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Hi Dave,
thank you for testing.
Quote from: dedndave on April 28, 2014, 12:05:50 AM
i didn't notice SAHF/LAHF on any of the other processors, which i think they should support
although it applies to 64-bit mode, it's nice to know if the feature is present, even in 32-bit
I'll think about it. Shouldn't be to hard to implement.
Quote from: hutch-- on April 27, 2014, 11:42:57 PM
Here is the later one on my old quad.
that seems what it should be. Thank you.
Gunther
Hi Biterider,
thank you for your effort, but the update is Iset32U1.zip.
Hi Fortrans,
the GPF makes me wonder. What happened exactly?
Gunther
Quote from: Gunther on April 28, 2014, 01:46:30 AM
the GPF makes me wonder. What happened exactly?
Hi Gunther,
I opened an MS-DOS session, and ran the program. Then the
error dialog popped up, no other output was seen. I copied the
error information, closed the dialog, exited the session, and tried
to shut down the laptop. Windows complained of a program that
would not close, and I had to reset it to shut it off.
Regards,
Steve N.
Hi,
Noting that you had a .686P directive in your assembler code,
and that the P-MMX is a .586, I tried an experiment. I booted up
my other Windows 98 machine, with a P-II CPU, and ran your
program on it. It ran successfully, and here are the results.
There are some differences in how the two machines are set up.
(At least they work some things a bit differently.) So, I suppose it
could be one of those differences that allowed your program to run.
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Not supported.
Instruction Sets
----------------
MMX
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Please, press enter to end the application ...
HTH,
Steve N.
Hi Steve,
Quote from: FORTRANS on April 28, 2014, 03:23:41 AM
Noting that you had a .686P directive in your assembler code,
and that the P-MMX is a .586, I tried an experiment. I booted up
my other Windows 98 machine, with a P-II CPU, and ran your
program on it. It ran successfully, and here are the results.
thank you. I think it has to do with some Windows 98 behavior.
Gunther
I've found that the behavior of Windows 7 Professional (64 bit) is different than the 32-bit version. Here's the 64-bit output:
Quote
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-3770CPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Please, press enter to end the application ...
AVX is supported. Here's the 32-bit output, same machine, but running is VM under VirtualBox:
Quote
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-3770CPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Please, press enter to end the application ...
No AVX. Both operating systems are running with SP 1. That's a bit strange, isn't it?
Gunther
Hi
Gunther,
Quote from: Gunther on April 28, 2014, 01:46:30 AM
the GPF makes me wonder. What happened exactly?
there was cmove ecx,ebx instruction executed which isn't supported by PMMX, probably it was generated by C compiler, if the compiler will optimize your code for 586 line the program will work on PMMX too :t
Results are proper
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Celeron(R)CPU2.13GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
Please, press enter to end the application ...
Just a note: The information about crash reason was found thanks to Steve's (FORTRANS') dump data :t
Hi Alex,
Thanks for the analysis. I guess I should read up on CMOV,
and see if there is an easy test for its existence or absence.
Cheers,
Steve N.
Hi Steve,
I did not notice CMOV in the ASM source, too, I think it is the code produced by C compiler, i.e. the HLL compiler optimized the code for 686 and later machines and used appropriate instuctions, like CMOV, where it was required. So the way to fix the program is just to recompile the C sources with optimization for 586 machines. Though at the moment no C compiler around to check this.
Alex,
Quote from: Antariy on April 29, 2014, 07:08:56 AM
there was cmove ecx,ebx instruction executed which isn't supported by PMMX, probably it was generated by C compiler, if the compiler will optimize your code for 586 line the program will work on PMMX too :t
thank you for helping. Good catch. :t I'll re-compile the C source.
Gunther
Hi,
Quote from: Antariy on April 29, 2014, 08:17:10 AM
I did not notice CMOV in the ASM source,
Right. I replaced the .686P directive with a .586, and the code
assembled with the same results both ways. One line caused ML
6.14 to complain either way. So it had to be something else.
Either the C code or the Windows environment between the two
machines. I had no way to test those in any meaningful way.
I was going to look up the opcode in the error message, but
you did that first. (Another problem would be me trying to determine
when (which processor version) an instruction was introduced.
I do not have that information at hand here.)
Regards,
Steve N.
Supported Features by Processor and Operating System
====================================================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-4770KCPU@3.50GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
FMA (Fused Multiply Add) extensions using YMM state.
16-bit floating-point Conversion Instructions
Regards, Biterider
Thank you Biterider for testing the application. Good processor (Haswell microarchitecture with AVX 2). :t Have you already used the new instructions?
Gunther
Under the first post of this thread you'll find the archive Iset32U2.zip. It's an update. The C source is now compiled for an 80386 and should run without a crash on older processors, too. I've changed the program logic.
- The application checks first the instruction sets, which are available.
- If the CPUID instruction is available, it checks for Vendor String and Brand String.
- The application checks additional features.
The program has now the following output:
Quote
Supported Features
==================
Vendor String: GenuineIntel
Brand String: Intel(R)Core(TM)i7-3770CPU@3.40GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions
Please, press enter to end the application ...
Your test results both old as well as new machines, your comments and proposals are welcome.
Gunther
Quote
Supported Features
==================
Vendor String: GenuineIntel
Brand String: Intel(R)Celeron(R)CPUE3400@2.60GHz
Instruction Sets
----------------
MMX SSE SSE2 SSE3 SSSE3
Supported Special Instructions
------------------------------
Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
Gunther
as far as i am able to determine, the 80386 + windows combination is very unlikely
well - anything newer than windows 3.1, at least, which wouldn't run a PE file
it's hard to find documented history indicating there were any 386 embedded controllers with windows ce
that would be the only case where a PE file might run on a 386
Dave, Win32s is the "extender" for Win3.1 which allows to run regular 32 bit PE files.
Quote from: Gunther on May 02, 2014, 09:16:39 PM
Under the first post of this thread you'll find the archive Iset32U2.zip. It's an update. The C source is now compiled for an 80386 and should run without a crash on older processors, too.
[...]
Your test results both old as well as new machines, your comments and proposals are welcome.
Hi Gunther,
It is still faulting on the P-MMX. And the error looks similar.
CPU executed an invalid instruction in
module CPU.EXE at 0167:004036b0.
Registers:
EAX=80000000 CS=0167 EIP=004036b0 EFLGS=00010246
EBX=0074fa98 SS=016f ESP=0074fa80 EBP=0074fd58
ECX=c14b27d0 DS=016f ESI=0074fcdd FS=0e47
EDX=00008000 ES=016f EDI=0074fa94 GS=0000
Bytes at CS:EIP:
0f 44 c2 8d 53 02 0f 44 da 00 c0 83 db 03 29 fb A suggestion: Could you put a version label of some sort at
the top of the output? Something like; Author, Purpose, Version,
and Date or a subset of those? Certainly not required, but would
be nice.
Regards,
Steve N.
Hi Steve,
did you use the right archive?
Gunther
here is some code i wrote a few years back
maybe Gunther will find it useful :P
pushfd
mov ecx,240000h ;bit 21 = ID, bit 18 = 386/486
pop eax
mov edx,eax ;EDX = original
xor eax,ecx ;EAX = toggled
push eax
popfd ;EFLAGS = new
pushfd
pop eax ;EAX = new
push edx
popfd ;EFLAGS = original
xor eax,edx ;EAX = toggle result
and eax,ecx
;if EAX bit 18 is set, CPU is 486 or higher
;if EAX bit 21 is set, CPU supports CPUID instruction
;no versions of the 386 supported CPUID
;late versions of the 486 support CPUID
Quote from: Gunther on May 03, 2014, 02:28:57 AM
Hi Steve,
did you use the right archive?
Hi Gunther,
I hope so...
02-05-14 12:03a 93,895 CPU.EXE
02-05-14 09:58a 43,832 Iset32U2.zipRegards,
Steve
Hi Gunther, after some debugging I found that it seems that the problem is in the static CRT that is used by the compiler, it uses the instruction which causes a fault, in more details there is a code which searches for some dlls, and in the code which does this there are those instructions (CMOVs).
I recompiled your program with MSVC10 and CRTDLL.DLL, the file attached. The source is original.
Hi Alex,
Quote from: Antariy on May 03, 2014, 02:40:45 AM
Hi Gunther, after some debugging I found that it seems that the problem is in the static CRT that is used by the compiler, it uses the instruction which causes a fault, in more details there is a code which searches for some dlls, and in the code which does this there are those instructions (CMOVs).
thank you. Good catch. :t I'll incorporate your EXE into the archive. It is now Iset32U3 and contains 2 subdirectories: \Iset32U3\GCC contains the GCC related files, including cpu.exe. \Iset32U3\MSVC10 contains only cpu.exe, generated with MSVC.
Gunther
You are welcome, Gunther! :t
Hi Alex,
Here is the result of the program from Reply #56 from my
P-MMX laptop.
Supported Features
==================
Vendor String: GenuineIntel
Brand String: Not supported.
Instruction Sets
----------------
MMX
Supported Special Instructions
------------------------------
Please, press enter to end the application ...
Regards,
Steve N.
Alex,
it should run now on older processors without problems, I hope. I've to figure out, how to link the right CRT.
Gunther
Hi Steve,
Quote from: FORTRANS on May 03, 2014, 03:12:43 AM
Hi Alex,
Here is the result of the program from Reply #56 from my
P-MMX laptop.
Supported Features
==================
Vendor String: GenuineIntel
Brand String: Not supported.
Instruction Sets
----------------
MMX
Supported Special Instructions
------------------------------
Please, press enter to end the application ...
is that the machine, which crashed? If not, try the cpu.exe generated by Alex. Thank you.
Gunther
Hi Steve, thank you for test! Also for dump info which helped to locate the fault :t
Gunther, yes it should run now on older machines, not sure about 386 but exactly PPlain. Probably 386-486 too, because I used CRTDLL.DLL as a runtime which is shipped with every Win32 version since WinNT 3.x, not MSVCRT.DLL which is shipped with Win98 and later, and must be installed separately for Win95 (early versions). I'm not sure this DLL is shipped with modern Windows versions, the EXE runs on your machine, it's Win7 x64 isn't it? Then this dll is shipped with Win7 too, interesting if it is shipped with Win8 :biggrin:
Gunther, if the GCC linker supports "Microsoft type" of import libraries then you may try to use the tool
\masm32\tools\makecimp
to create the CRTDLL import library and then use it when linking.
Just rename all the files in the directory MSVCRT.* to CRTDLL.* and edit makevcrt.bat appropriately to change filenames, and then run the bat file and you'll get the import library. But the library will be without the standard startup code, which, for example, provedes the arguments for main(), and causes a fault which has discussed here. If the linker of GCC provides a way to change the entry point, then you may, for your program, just specify the entry as a name of main() as well as add into main() the exit(0); instead of return 0; and the program will be independed from startup code, i.e. it will be smaller and faster to run, and will import only 3 functions from the DLL.
If you would like to have the fully workable replacement of the startup code for the console-type programs (i.e. with standard main(argc, argv, environment) for MSVCRT and CRTDLL then I may find and post them, I posted the replacement for MSVCRT startup code in your thread with Monte-Carlo program which was recompiled with MSVC10.
Probably this post requires to be set as a different thread about CRT libraries :biggrin:
Hi Gunther,
Quoteis that the machine, which crashed?
Yes it is. Using the version from Alex.
Quote from: Antariy on May 03, 2014, 03:22:26 AM
Hi Steve, thank you for test! Also for dump info which helped to locate the fault :t
You are welcome.
Also I tried it with a Win32S system, which did not work.
Probably a good thing as I would have had to put a Pentium
(plain) system back together.
Regards,
Steve N.
Steve,
Quote from: FORTRANS on May 03, 2014, 03:52:05 AM
Also I tried it with a Win32S system, which did not work.
Probably a good thing as I would have had to put a Pentium
(plain) system back together.
that would be great. :icon_cool:
Gunther
Steve, which is the version of your Win32s subsystem? And how does it refuse the program to run - any messages? Also I'm not very understand the phrase about PPlain, complex tenses - I have problems with them :biggrin: You mean the program is not working because of PPlain and not PMMX? But the EXE doesn't contains MMX instructions, so it should work on PMMX, too, probably the problem is with compatibility with Win32s, maybe with the version of it (if the version is lower than 1.15 then the EXE will not be workable due to subsystem version in the PE file).
Gunther, I have posted the info about startup replacement which may interest you, here: http://masm32.com/board/index.php?topic=3167.msg32861#msg32861
Win32S was a hybrid that will not run proper Win32 PE files.
PPLAIN = very early Pentium that did not have MMX.
From about 200 MH the Early Pentiums supported the MMX instruction set. I owned a 166 Pentium long ago that did not support MMX.
Hi,
Quote from: Antariy on May 03, 2014, 04:05:19 AM
Steve, which is the version of your Win32s subsystem?
Version 1.25 in an OS/2 VDM.
QuoteAnd how does it refuse the program to run - any messages?
Yeah, an error number and "Wrong Format". I can get the
exact words next time I boot it up.
Quote
Also I'm not very understand the phrase about PPlain, complex tenses - I have problems with them :biggrin: You mean the program is not working because of PPlain and not PMMX?
No. I ran your program on a P-III with Win32S. The Pentuim
with Win32s is not active at the moment.
QuoteBut the EXE doesn't contains MMX instructions, so it should work on PMMX, too, probably the problem is with compatibility with Win32s, maybe with the version of it (if the version is lower than 1.15 then the EXE will not be workable due to subsystem version in the PE file).
Yes, it worked on the P-MMX as reported above. That was
using Win98. It failed on a P-III with Win32s 1.25.
Regards,
Steve N.
Quote from: hutch-- on May 03, 2014, 04:19:30 AM
Win32S was a hybrid that will not run proper Win32 PE files.
PPLAIN = very early Pentium that did not have MMX.
From about 200 MH the Early Pentiums supported the MMX instruction set. I owned a 166 Pentium long ago that did not support MMX.
Hi
Steve, yes I understand what was meant under PPlain, the proggie I posted will work on PPlain, too, since it doesn't contain MMX instructions. What was not understandable is the "Probably a good thing as I
would have had to put" - many tenses in a mix :biggrin:
Win32S may properly run decently complex programs, too, even written in "too high level languages" like earlier version of 32 bit Delphi compilers, but the subsystem is crazy ::) Probably Gunter's program should run on Win32s if it will be "sharpened" for it (playing with subsystem version of PE file etc) as it has very modest requirements from the OS. But probably optimizing the program for the such a hybrid is not useful.
Quote from: FORTRANS on May 03, 2014, 04:23:33 AM
Hi,
Quote from: Antariy on May 03, 2014, 04:05:19 AM
Steve, which is the version of your Win32s subsystem?
Version 1.25 in an OS/2 VDM.
QuoteAnd how does it refuse the program to run - any messages?
Yeah, an error number and "Wrong Format". I can get the
exact words next time I boot it up.
Steve, thank you for detailed information :T
I have no experience with Win32s running on OS/2 at all, only some on Win3.1 so it's hard to say what is wrong with the format.
When and if you would like, may you change the subsystem of the EXE to 3.1, using the linker:
LINK /EDIT /SUBSYSTEM:CONSOLE,3.1 cpu.exe
to change the subsystem, and then dump the exe
LINK /DUMP cpu.exe
to check if the subsystem had changed. If it changed then try it with Win32s again, but not sure it will change something. Of course this is for your decision of it's not bother you, just out of curiousity.
Hi Alex,
Interesting idea, but something went wrong.
G:\masm32\bin>LINK /EDIT /SUBSYSTEM:CONSOLE,3.1 A:CPU.EXE
Microsoft (R) COFF Binary File Editor Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
G:\masm32\bin>LINK /DUMP A:CPU.EXE
Microsoft (R) COFF Binary File Dumper Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file A:CPU.EXE
A:CPU.EXE : warning LNK4048: Invalid format file; ignored
Summary
And the program crashed the VDM with windows.
Regards,
Steve
Thank you, Steve!
The program with changed subsystem was not dumped, and when it was run it crashed the VM which has run windows?
I have attached some files more, playing with the format a bit, if you would like to check them in sometime, try them in the descending order. Some of them may crash the VDM, too, probably. Also for your decision as it is just out of curiousity.
I understand that the command to change the subsystem version was mistyped ::) Instead of /SUBSYSTEM:CONSOLE,3.1 it is proper to use 3.10
So the need not to test exes from the archive above because some of them linked with mistyped version.
Hi Alex,
The error message from Win32s is a popup that says (sort of)
"Win32s", "CPU.EXE: Invalid format". Clicking on that brings closes
it and brings up "Cannot Run Program", "Unexpected error 21".
Looking for information I found http://stephan.win31.de/w32slist.htm (http://stephan.win31.de/w32slist.htm).
Where it says:
Quote[Someone had encountered an Error 21/"Invalid Format" message from Win32s]
Unfortunately the VC++ 5 and 6 compilers default to not generate a .reloc section
in applications so the .EXE can be loaded only at its fixed base address (default
0x400000) that is not available in Win32s.
Is adding a .reloc section difficult with MASM?
Regards,
Steve N.
P.S. Interesting when a search for new information turns up your
own posting. Grr.
Hi Steve,
Quote from: FORTRANS on May 07, 2014, 01:19:29 AM
Is adding a .reloc section difficult with MASM?
not sure, but would help this thread (http://forum.pellesc.de/index.php?topic=2910.0)? May be that Erol (aka Vortex) knows how to fix that.
Gunther
Hi Gunther,
Thank you. I will try that later.
Regards,
Steve N.
Hi Steve,
Quote from: FORTRANS on May 07, 2014, 04:32:27 AM
Thank you. I will try that later.
okay. Don't rush.
Gunther
Hi,
I tried the linker switch /FIXED:NO as mentioned by Vortex.
And assembled a small program that is using;
include \masm32\include\masm32rt.inc
And it then wants MSVCRT.DLL, so copy that over. Then
it trys to load, and fails with "Win32s - error", "The procedure
entrypoint "HeapCompact" could not be located in [...]". So
I would guess I need a simpler set of includes to replace
masm32ft.inc. And so I will look in the examples subdirectory to
see what I can find.
Regards,
Steve N.
Hi Steve, thank you very much for the information, did not know that :t
Yes, I removed (as usually) the relocations from the EXE - the MSVC10 produces .reloc section by default but I turned it off with /FIXED switch. Now recompiled the EXE with relocs :t
Can you try it out? Two exes, one is 4.0 subsystem version, the other is 3.10
Hi Alex,
Tried both on two systems. With both I used File Manager,
selected the EXE, went to File, run, and the run dialog comes up.
Clicking on that and the dialog goes away. No messages or
anything else as far as I can tell. I also tried just double clicking
it, and except for an instant of disk activity, nothing happens.
HTH,
Steve N.
Steve, thank you! :biggrin:
Steve,
Quote from: FORTRANS on May 07, 2014, 09:23:59 AM
Tried both on two systems. With both I used File Manager,
selected the EXE, went to File, run, and the run dialog comes up.
Clicking on that and the dialog goes away. No messages or
anything else as far as I can tell. I also tried just double clicking
it, and except for an instant of disk activity, nothing happens.
seems to be a good sign.
Gunther
Hi,
I looked in the "masm32\examples" directory for console examples
that did not use masm32rt.inc, and selected a few. Here are the first
results for running with Win32s in a VDM.
dosstyle.asm : requires MSVCRT.DLL, does not work.
hello.asm : disappears, does not work.
MemInfoMicro.asm : works, but it is a dialog and not a console application.
MemFree.asm : did not assemble due to errors.
Comments? Suggestions?
Regards,
Steve N.
Hi Steve,
Quote from: FORTRANS on May 08, 2014, 02:31:21 AM
dosstyle.asm : requires MSVCRT.DLL, does not work.
hello.asm : disappears, does not work.
MemInfoMicro.asm : works, but it is a dialog and not a console application.
MemFree.asm : did not assemble due to errors.
that doesn't sound great. But look Win32s was designed between Windows 3.1 and Win95 and the "s" stands for "subset". I think that explains some things.
Gunther
Hi
Steve,
Quote from: FORTRANS on May 08, 2014, 02:31:21 AM
I looked in the "masm32\examples" directory for console examples
that did not use masm32rt.inc, and selected a few. Here are the first
results for running with Win32s in a VDM.
dosstyle.asm : requires MSVCRT.DLL, does not work.
hello.asm : disappears, does not work.
MemInfoMicro.asm : works, but it is a dialog and not a console application.
MemFree.asm : did not assemble due to errors.
Comments? Suggestions?
I thought about that it maybe something with console type programs, but did not spoke that "aloud" because though that I already got much of your patience with the question, and did not want to be boring :biggrin:
MSVCRT.DLL was first shipped with Win98/late Win95 as a system DLL, so instead of linking with MSVCRT.lib you may link the program with CRTDLL.LIB - I described in previous page how to do the import library for CRTDLL.DLL. But probably that has nothing to do with our question, i.e. if we put MSVCRT.dll on the system or relink with CRTDLL.dll the program won't run because of other reason.
MemInfoMicro - this name is familar :biggrin: Yes, it's not a console program but uses a MessageBox which brings up the dialog. Maybe the reason is really in the console programs?
Hi
Gunther,
Quote from: Gunther on May 08, 2014, 02:54:41 AM
that doesn't sound great. But look Win32s was designed between Windows 3.1 and Win95 and the "s" stands for "subset". I think that explains some things.
Yes, you're right, the Win32s is not a widely spread system, so your program covers the most of the OSes, but it is just a curious technical problem - why a programs didn't work on it :biggrin:
Just vaguely I remember that you needed a specialised linker to build a win32S application. It is hybrid crap technology bridging win16 to a test format of 32 bit written underneath in 16 bit. They ran on win16 (3.11) but nothing fancy.
Hi,
Quote from: Antariy on May 08, 2014, 03:36:34 AM
Maybe the reason is really in the console programs?
Yes, it is looking like console programs are not supported. Could
not even find an MS-DOS command prompt/box. Oh well.
Quote from: hutch-- on May 08, 2014, 03:45:28 AM
Just vaguely I remember that you needed a specialised linker to build a win32S application.
Well the program that worked with Win32s was linked with the
linker that came with MASM32.
Regards,
Steve N.
Hi Steve,
Quote from: FORTRANS on May 08, 2014, 05:53:51 AM
Quote from: hutch-- on May 08, 2014, 03:45:28 AM
Just vaguely I remember that you needed a specialised linker to build a win32S application.
Well the program that worked with Win32s was linked with the
linker that came with MASM32.
that could perhaps help (http://digitalmars.com/ctg/win32programming.html) a bit.
Gunther
i seem to recall we went through all this 5 years ago when i was working on the OS ID stuff :P
http://www.masmforum.com/board/index.php?topic=11963.msg91220#msg91220 (http://www.masmforum.com/board/index.php?topic=11963.msg91220#msg91220)
Hi Dave,
Good memory!
Cheers,
Steve
Dave,
Quote from: dedndave on May 08, 2014, 06:09:59 AM
i seem to recall we went through all this 5 years ago when i was working on the OS ID stuff :P
http://www.masmforum.com/board/index.php?topic=11963.msg91220#msg91220 (http://www.masmforum.com/board/index.php?topic=11963.msg91220#msg91220)
yes, excellent power of recall. :t
Gunther
Hi,
QuoteCould not even find an MS-DOS command prompt/box.
Well, that was stupid. Just find something that can run a program,
and launch COMMAND.COM. In a VDM it is the same as a direct
invocation of a VDM. With MS-DOS and Win 3.11, you lose a bit of
usable memory compared to pure DOS, but you get prompt of
the hot keys to switch back to Windows.
Regards,
Steve N.
not sure i understand what you're saying, Steve
as i recall, to get a command prompt in win 3.1, you exit windows
it is essentially a shell that runs under command.com
it's been a long, long time - and i wasn't much of a win 3.1 fan back then
so, i may have the facts thoroughly mangled - lol
Dave,
Under Win3.0/1/11 you could get an instance of command.com while in Windows, it had less memory than a direct instance of command.com in DOS but did most things OK. If you wanted the real McCoy you exited Windows to DOS. There were the odd situations that Windows squarked at with a DOS prompt which followed from its ugly cooperative multitasking and if you needed some direct hardware access you had to exit to DOS.
Steve,
Quote from: FORTRANS on May 08, 2014, 11:40:45 PM
Well, that was stupid. Just find something that can run a program,
and launch COMMAND.COM. In a VDM it is the same as a direct
invocation of a VDM. With MS-DOS and Win 3.11, you lose a bit of
usable memory compared to pure DOS, but you get prompt of
the hot keys to switch back to Windows.
would it be a better solution to compile the entire thing with a 16-bit C compiler (for example Turbo C) and link against the 16-bit assembly procedure? All that Jazz with Win32s.
Gunther
Hi Gunther,
Well if you want the results from a Pentium, go ahead. I
don't think a Win32s console program is going to work. I was
just trying things out just to see if I could get things working
with Win32s, and got a bit carried away. Well I did get the
one example program to work.
Regards,
Steve N.
Steve,
Quote from: FORTRANS on May 09, 2014, 07:05:56 AM
Well I did get the one example program to work.
no offense. It was just an idea. But your result sounds optimistic. Do you think that the other applications will work, too?
Gunther
Hi Dave,
Quote from: dedndave on May 09, 2014, 02:32:33 AM
not sure i understand what you're saying, Steve
as i recall, to get a command prompt in win 3.1, you exit windows
it is essentially a shell that runs under command.com
Hutch explained it pretty well. And I had never used a DOS
session under Windows 3.x, (IIRC...). Which is why I could not
figure out how to do it.
Regards,
Steve N.
Hi Gunther,
Quote from: Gunther on May 09, 2014, 07:09:52 AM
no offense. It was just an idea.
And probably a good one if want to run any tests on my plain
Pentium systems. The Pentium MMX with Win 98 works for
most programs now. And it should show identical cycle results
anyway.
QuoteBut your result sounds optimistic. Do you think that the other applications will work, too?
Well I got a dialog program to work, maybe something
could be made to work that way. And write the results to
a file.
I just got involved for the idea that it might be a way to
get me to start programming in the 32-bit world. Win32s
has been a fun diversion if nothing else.
Regards,
Steve N.
Hi Steve,
Quote from: FORTRANS on May 09, 2014, 07:29:52 AM
And probably a good one if want to run any tests on my plain
Pentium systems. The Pentium MMX with Win 98 works for
most programs now. And it should show identical cycle results
anyway.
yes, but I need a few days for finishing the 16-bit version.
Gunther