A New Testbed for MASM32 Forum

[frktons]

yes - well - if you serch the forum, Jochen, Hutch, and I have all attacked CPU identification to one degree or another - lol
it's a bag of worms, at best
but there are routines that create these strings already

let me see if i can find them....

Hi Dave, I suppose this is for me.
I'll have a look at them and see what I can find.

Frank

[frktons]

This is the first bare bone release of the New Testbed.

It should work on OS from win 2000 up to win7, 32/64 bit and CPU
from PIII, and maybe previous one as well.
It should assemble with MASM 6.15 up to 10.

Now it uses short filename 8.3 old standard, in case somebody is still
using very old OS.

Not all is complete, but it works good enough for main functions:

1) detect OS version
2) detect CPU version [still something to implement I guess, but it depends on Alex  :P ]
3) 12 algos mode - still uncomplete 24 algos mode
4) Rerun the test without exiting the program
5) save the entire colored screen with results to disk file
6) read back saved files
7) save/restore screen when displaying Help or saved files


The remaining part is quite big as well, the To do list has:

1) 24 algos mode
2) Copy the text to the clipboard in order to paste it into the Forum
3) Info screen/s
4) internal coding of external files, reducing the overall size of 50-70%
5) a template to insert the algos to test, the one inside is not optimized
6) maybe something else...

Attached the version 1.00

If you like, try to run it, to compile it, and report any problem you can find.

Frank



 

[Antariy]

Code Select Expand


├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ    │    64   │    9.579 │    9.574 │    9.575 │    9.583 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP        │    43   │   14.049 │   14.056 │   14.070 │   14.036 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA   │    44   │    4.613 │    4.642 │    4.625 │    4.619 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ  │    64   │   11.736 │   11.683 │   11.687 │   11.683 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT        │    42   │   13.944 │   13.932 │   13.965 │   13.947 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤


[Antariy]

It should work on OS from win 2000 up to win7, 32/64 bit and CPU

I guess, it should work on Win98 and ME, too :P

[frktons]

Hi Alex, glad to see you are here.  :U

The program is usable even if not all the extras are ready.  :P

As main contributor, you should be happy as I am that the job we
have done is shaping well and probably suits some of the Masm32
Forum needs, at least the needs of some of the users.

I guess, it should work on Win98 and ME, too :P

I don't know that until somebody uses it on those OS.


Frank

[Antariy]

Frank, it is compiled with errors with ML v.1.0 :P That is joke  :bg

I have compiled it with ML6.15 and ML8 - it forks fine  :U

[Antariy]

I guess, it should work on Win98 and ME, too :P

I don't know that until somebody uses it on those OS.

:P

[frktons]

Frank, it is compiled with errors with ML v.1.0 :P That is joke  :bg

I have compiled it with ML6.15 and ML8 - it forks fine  :U

This is mainly due to your collaboration.  :U
I only use Win 7/64 bit and ML 10, I'm not aware of the
many compatibility problems that can arise changing MASM versions,
OS versions, CPU versions...

Only with the help of the people who have tested it on their machines
I've discovered things that had to be changed as well.

Frank

[Antariy]

Since Dave was strongly worried about the "too much printed infos" about CPU - there is a workaround.

Frank are removed this from his source, but initially sources (posted many pages ago) have my comments, so:

Code Select Expand


.....
; Return values:
;  low order WORD of EAX:
;  instructions supported:
;  0 - need upgrade
;  above 0 - then supported:
;  1 - MMX
;  2 - SSE1
;  3 - SSE2
; 4 - SSE3
;  5 - SSSE3
;  6 - SSE4.1
;  7 - SSE4.2
; high order WORD of EAX:
; size of the output string in chars, without termination null


align N16

AxCPUid proc lpStrOut:DWORD
.....


As Dave can see - code returns the *maximal* instruction set in the lower WORD of the EAX.

So, that is not big deal to print out only maximal (latest) instuction set from all present :P


EDITED: you can enjoy with really unpredictable and truely great feature of the code formatting engine (of the forum software)  :green2



Alex

[hutch--]

 :bg

Frank,

One request, put all the stuff at the start in an include file, you have to wade through screen after screen of stuff that not much use to you just to find the start of the code.

[frktons]

Since Dave was strongly worried about the "too much printed infos" about CPU - there is a workaround.

Frank are removed this from his source, but initially sources (posted many pages ago) have my comments, so:

Code Select Expand


.....
; Return values:
;  low order WORD of EAX:
;  instructions supported:
;  0 - need upgrade
;  above 0 - then supported:
;  1 - MMX
;  2 - SSE1
;  3 - SSE2
; 4 - SSE3
;  5 - SSSE3
;  6 - SSE4.1
;  7 - SSE4.2
; high order WORD of EAX:
; size of the output string in chars, without termination null


align N16

AxCPUid proc lpStrOut:DWORD
.....


As Dave can see - code returns the *maximal* instruction set in the lower WORD of the EAX.

So, that is not big deal to print out only maximal (latest) instuction set from all present :P


EDITED: you can enjoy with really unpredictable and truely great feature of the code formatting engine (of the forum software)  :green2



Alex

We'll see what the requests are and what is doable.  :P

As forecasted, when the project started a couple of months ago,  I asked
the opinion of the forum guys in order to build this tool according to the
taste and need of regular forum users, but only Alex expressed his opinion and
helped me in a practical way as well. Some comments from Hutch, recentely
Dave started to join the fellowship  :wink, and probably nothing else.

But I told  Alex to be assured that when the first release would come out,
somebody would start asking for this feature or the other.

Assembly Programmers are not that much different in this field than your
customers, who come up with requests only when the job is almost done.  :lol

That was the first post of this thread:

Hi all guys.

I've been thinking about this project for a couple of months.
Maybe now I've quite enough knowledge to realize it.

Before embarking into this trip, I'd like to ask your opinion,
suggestions, and availability to help if needed to code a new testbed
with a more friendly interface, with the possibility to relaunch the test,
visualizing info inside a grid with:

Algorithm notes  |   Proc size  |  CPU cycles

for about 10 different algos with two sections for first and second test
on two separate side by side grids, other than:
CPU type / Windows version / any other useful info.

Let me know what do you think about it.

Frank

  Isn't that funny?  :lol

:bg

Frank,

One request, put all the stuff at the start in an include file, you have to wade through screen after screen of stuff that not much use to you just to find the start of the code.

This should be doable, and makes sense to me as well. I'll try to leave the algos code
at the beginning of the program, or maybe it is even better to have them, the tested
part  I mean, in include files as well, making them separate objects you can see and change
without editing the main program at all?

If you have something like : algo1.inc, algo2.inc, algo3.inc that are a dozen lines of code to test
each, wouldn't it be simpler to manage, read, change them?

Now that the time for requests has come, let's see together which is the most comfortable
way of doing things.

I'll not change everything in a few days, but I'll see what the requests are, think about them
and discuss them with you. When we find a doable solution that suits the taste and need
of the many, I'll start reconding, if necessary, pieces of PROCs and program structure.

Frank

[FORTRANS]

Hi Frank,

   Coming over from the other posting.  The new one works
fine on the PIII with Windows 2000.

We'll see what the requests are and what is doable.

   Human readable please.  Some abbreviation allowed.  Like
maybe?

CPU: Intel(R) Core(TM)2 Quad CPU Q???? @ 3.14 GHz with MMX, SSE 1, 2, 3, 4.1, SSSE3

I guess, it should work on Win98 and ME, too

   Well, it starts out fine, but then dies with an invalid instruction
error message on my Windows 98 machines.  Maybe you
could skip tests with unsupported instruction sets?  You do
have the information for printing the CPU version.

Thanks,

Steve N.

[Antariy]

Hi to all!

Now I come for short time only.

Here is version which make short description for the CPU. AxCPUid proc was adapted for testbed.

The brand name of CPU (or model-family), number of logical cores, and maximal supported instruction set is printed out.

New screen :

Code Select Expand


┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS  : Microsoft Windows XP Professional Service Pack 2 (build 2600)                     │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz about 1 logical core(s) with SSE3                 │
│                                                                                        │
│Test: Conversion of a screen buffer from DOS to Windows CHAR_INFO structure             │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ    │    64   │    7.068 │    7.077 │    7.087 │    7.073 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP        │    43   │   13.164 │   13.498 │   13.037 │   13.012 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA   │    44   │    4.421 │    4.415 │    4.380 │    4.465 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ  │    64   │   11.126 │   11.082 │   11.079 │   11.081 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT        │    42   │   13.029 │   13.023 │   13.013 │   13.018 │
├──────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┤
│ Esc   Exit    F1 Help    Copy     Run       View       Save       Display 12   Info    │
└────────────────────────────────────────────────────────────────────────────────────────┘


Test it, please.



Alex

[Antariy]

Under peoples pressure we are striked out all non-Intel CPUs from the History :P

[Antariy]

I guess, it should work on Win98 and ME, too

   Well, it starts out fine, but then dies with an invalid instruction
error message on my Windows 98 machines.  Maybe you
could skip tests with unsupported instruction sets?  You do
have the information for printing the CPU version.

Probably, nobody understands me :(

As I sayed at ~3 posts above - the AxCPUid (Frank's adapted name) is returned the maximal supported instruction set in the AX. So - that is not problem to skip something code from test, if it is require instructions which is higher that result returned by AxCPUid in AX.

That is question for the testbed architecture - maybe Frank will implement exclusion of not supported code.



Alex