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
Here I post the first draft of the screen in which the algos
are tested and measured.
It is a prototype in basic, before going into MASM I'd like to see
what would you like to change.
Frank
Of course the screen can be done any suitable size, combination of colors,
quantity of info displayed, type of data formatting and so on.
I just need to know if it has to be a simple exercise in MASM32 coding
for me, and it'll be fine anyway, or if you think it can also be useful for
the forum where a lot of tests are performed all over the year.
Let me know your opinion.
I'll enjoy coding it either cases.
Frank
Frank, if you make this is simple for addition and supporting of algos - this is nice app (i.e. - testbed)!
You can rewrite it from PB, indeed.
Alex
Frank, what is switch the background color with grid and text color?
Alex
Frank, this is my taste only (blue background and bright white text), I don't impose this at all.
Alex
Quote from: Antariy on September 21, 2010, 08:54:15 PM
Frank, this is my taste only (blue background and bright white text), I don't impose this at all.
Alex
Yes, this is also what I like, I'll change it and post the new colored version.
Frank
These colors are more eye-friendly :-)
Well, in this version the program also create a file that contains the screen as well,
it is not needed for the coming work, I used it just to change the attributes.
Doesn't matter, I'll get rid of it along the way.
Frank
This is really nice in look - as good DOS :)
Really, good for a eye look, indeed.
Alex
Quote from: Antariy on September 21, 2010, 10:27:09 PM
This is really nice in look - as good DOS :)
Really, good for a eye look, indeed.
Alex
This is only a temporary experimentation, I hope the final version will be
much better looking than this one, and maybe it could be better to give
the possibility to change the colors of the screen to the user, in order to
match their personal tastes.
Frank
No, Frank, I seriously: this is almost as my taste, and this is beautiful, I don't joked you, really!
I have many DOS apps which have similar color scheme in "GUI".
Alex
Quote from: Antariy on September 21, 2010, 10:44:42 PM
No, Frank, I seriously: this is almost as my taste, and this is beautiful, I don't joked you, really!
I have many DOS apps which have similar color scheme in "GUI".
Alex
There is something that I don't like in the actual look, I'll try
until I get a version that satisfies my taste. :-)
Frank
Frank, maybe change background of title of table text to blue?
Alex
This one is more compatible with my taste.
Nice looks :thumbu
One thing only - the gray background of title of table, and black teXt of title - it looks as DOS (black-and-white).
But in other things this have my taste also :)
Alex
P.S. don't listen me - make as you likes...
EDITED: teXt instead teSt - I'm entangled with exe and dlls and tests and, and... You understand, Frank ;-)
Frank,
For a testbed to be useful it must do the timings in REAL TIME, processors have not worked in clock ticks since the i486dx. (1990)
Quote from: hutch-- on September 22, 2010, 03:24:16 AM
Frank,
For a testbed to be useful it must do the timings in REAL TIME, processors have not worked in clock ticks since the i486dx. (1990)
Maybe somebody has already a routine to do it.
This part is quite difficult for me to manage for the time being.
Any help is welcome.
Frank
Frank,
testing in real time has every irritation you can imagine, processor load variation, OS interference and considerable difficulty in getting reliable times but its only saving grace is it comes a lot closer to how algorithms get used. basically you work out what the algo will be used for, design the data for test purposes then run it for at least a half a second to get something like reliable timings.
If the take off of an algo is important you gear it for short repeated data, if sustained rates of data is important you gear the data for long continuous processing with very large samples, basically the difference is between ATTACK and SUSTAIN.
Quote from: hutch-- on September 22, 2010, 12:59:18 PM
Frank,
testing in real time has every irritation you can imagine, processor load variation, OS interference and considerable difficulty in getting reliable times but its only saving grace is it comes a lot closer to how algorithms get used. basically you work out what the algo will be used for, design the data for test purposes then run it for at least a half a second to get something like reliable timings.
If the take off of an algo is important you gear it for short repeated data, if sustained rates of data is important you gear the data for long continuous processing with very large samples, basically the difference is between ATTACK and SUSTAIN.
I gladly postpone this argument to a later date. :P
Frank
Hi all guys. :bg
Eventually I got a couple of free hours, and I coded some of the routines
needed to display the Screen Interface for the New Testbed.
It is just the grid structure to display the results of the tests.
Still missing:
1) Proc to Detect CPU type and PRINT it
2) Proc to Time the Algos and PRINT the elapsed CPU cycles
3) Proc to Format the numbers with point/comma thousand separator
4) Proc to Detect the Windows version and PRINT it
All the missing Procs are already around the forum, but I've not time
enough at the moment to search, adapt them and code them inside the
program. I'll do it as time permits.
Anybody who has already coded these Procs could adapt and insert them
inside the program structure attached and post the new version. :P
The actual structure of the program uses an external file that is the TextScreen
to display. I prefer to have it external because is easier to modify, if needed.
The program uses an Open File Dialog already set to pick the name of the
Text Screen File. In the final version both the external file and the Dialog
could possibly be unnecessary.
Any improvement in Speed, Completeness, Whatever are always welcome.
Frank
It looks good Frank, I have always liked crisp looking text mode interfaces.
I wonder how this PROC correctly works and the text screen
format is displayed. Looking at it, the content of eax after the first
mov is not cleared, and the next shl should bring 2 bytes that are
not zero in the positions where they shouldn't. ::)
; -------------------------------------------------------------------------
; The data read from the file is converted into CHAR_INFO style.
; ConsoleBuffer is filled with the content of FileBuffer, padding a zero
; after each byte making it Windows Console API displayable.
; -------------------------------------------------------------------------
ConvertArea PROC
lea esi, FileBuffer
lea edi, ConsoleScreen
mov ecx, BufChars
xor eax, eax
xor ebx, ebx
NextChar:
mov bx , WORD PTR [esi]
mov ah , bh
shl eax, 8
mov al , bl
mov [edi], eax
add esi, 2
add edi, 4
dec ecx
jnz NextChar
ret
ConvertArea ENDP
Frank
Quote from: frktons on October 31, 2010, 04:03:01 AM
I wonder how this PROC correctly works and the text screen
format is displayed. Looking at it, the content of eax after the first
mov is not cleared, and the next shl should bring 2 bytes that are
not zero in the positions where they shouldn't. ::)
; -------------------------------------------------------------------------
; The data read from the file is converted into CHAR_INFO style.
; ConsoleBuffer is filled with the content of FileBuffer, padding a zero
; after each byte making it Windows Console API displayable.
; -------------------------------------------------------------------------
ConvertArea PROC
lea esi, FileBuffer
lea edi, ConsoleScreen
mov ecx, BufChars
xor eax, eax
xor ebx, ebx
NextChar:
mov bx , WORD PTR [esi]
mov ah , bh
shl eax, 8
mov al , bl
mov [edi], eax
add esi, 2
add edi, 4
dec ecx
jnz NextChar
ret
ConvertArea ENDP
Frank
Frank, I guess, you are did repacking of DOS-like screen contents to the Windows-console screen-buffer contents?
Since CHAR_INFO have format:
typedef struct _CHAR_INFO { // chi
union { /* Unicode or ANSI character */
WCHAR UnicodeChar;
CHAR AsciiChar;
} Char;
WORD Attributes; // text and background colors
} CHAR_INFO, *PCHAR_INFO;
for unifyed usage with *Unicode* output and ASCII output, first member have size of WORD (2 bytes) - it is union, and contain WCHAR - which is Unicode UTF-16 char with size 2 byte (WORD). Second member is WORD, but higher byte have meaning for two-bytes character sets (like Japan) - i.e. complex scripts on Win9x-like implementation.
So, when you do your code, the EAX is
E A X:
#0byte #1byte #2byte #3byte
================================================
char code | garbage | color format | garbage
Sice you use WriteConsoleOutput
A, higher byte (AH) of the first member (Char) if the CHAR_INFO is ignored - it is used only in Unicode version. The same higher byte of EAX (#3) is ignored, sice it is just not used, because all colors specifyers is placed in lower byte.
So, your code just work on system (your system) - which made it right. If run it on Japan Win9x, or call to WriteConsoleOutput
W - results would be "undefined".
Alex
Yes Alex, I was thinking about that. I'll change it anyway along the path.
The program will have to change many times before it is ready.
In the next step release I'll correct it and make it a little bit faster :bg
Frank
Quote from: frktons on October 31, 2010, 11:43:43 PM
Yes Alex, I was thinking about that. I'll change it anyway along the path.
Probably, something like this:
Quote
..........
NextChar:
movzx eax , WORD PTR [esi]
shl eax,8
shr ax,8
mov [edi], eax
...........
Alex
Quote from: Antariy on October 31, 2010, 11:49:35 PM
Probably, something like this:
Quote
..........
NextChar:
movzx eax , WORD PTR [esi]
shl eax,8
shr ax,8
mov [edi], eax
...........
Alex
That is one possibility. I have used a different approach some months ago,
reading 4 bytes at a time from the source string and writing them to the
destination string like this:
Convert:
mov eax, [esi]
mov [edi], al
mov [edi+2], ah
bswap eax
mov [edi+6], al
mov [edi+4], ah
add esi, 4
add edi, 8
dec ecx
jnz Convert
but I don't know for the time being what's faster.
Frank
Quote from: frktons on October 31, 2010, 11:57:57 PM
That is one possibility. I have used a different approach some months ago,
reading 4 bytes at a time from the source string and writing them to the
destination string like this:
but I don't know for the time being what's faster.
Frank
This is almost the same, if you want use that code, but writes to subsequentry places:
Convert:
mov eax, [esi]
mov [edi], al
mov [edi+2], ah
shr eax,16
mov [edi+4], al
mov [edi+6], ah
add esi, 4
add edi, 8
dec ecx
jnz Convert
Hard to say what is faster on PIV - SHR is slow, and BSWAP too :green2
Alex
Quote from: Antariy on November 01, 2010, 12:05:27 AM
Quote from: frktons on October 31, 2010, 11:57:57 PM
That is one possibility. I have used a different approach some months ago,
reading 4 bytes at a time from the source string and writing them to the
destination string like this:
but I don't know for the time being what's faster.
Frank
This is almost the same, if you want use that code, but writes to subsequentry places:
Convert:
mov eax, [esi]
mov [edi], al
mov [edi+2], ah
shr eax,16
mov [edi+4], al
mov [edi+6], ah
add esi, 4
add edi, 8
dec ecx
jnz Convert
Hard to say what is faster on PIV - SHR is slow, and BSWAP too :green2
Alex
We timed it some months ago, and if I correctly remember BSWAP if faster than
SHR on the machines we tested. And using MMX registers to manage 64 bits at a time
is complicated because we have to pad a zero byte after each CHAR/ATTRIBUTE byte.
At least we have not tried to do it with MMX or SSE instructions, so far.
Frank
Quote from: frktons on November 01, 2010, 12:13:35 AM
We timed it some months ago, and if I correctly remember BSWAP if faster than
SHR on the machines we tested. And using MMX registers to manage 64 bits at a time
is complicated because we have to pad a zero byte after each CHAR/ATTRIBUTE byte.
At least, in poit of hardware, BSWAP must be slower than SHR, because SHR can and must work with the same physical register (set of bits) but BSWAP must use temporary place or delay lines.
But we does not know how implemented something in some CPU :green2 Anyway - SHR is incredible designed on PIV.
Alex
Quote from: frktons on November 01, 2010, 12:13:35 AM
And using MMX registers to manage 64 bits at a time
is complicated because we have to pad a zero byte after each CHAR/ATTRIBUTE byte.
At least we have not tried to do it with MMX or SSE instructions, so far.
Using of PUNPCKLBW will help a lot.
EDITED: for clearness - can interleave data bytes and padding zero, in this case.
Alex
Quote from: Antariy on November 01, 2010, 12:22:30 AM
Quote from: frktons on November 01, 2010, 12:13:35 AM
And using MMX registers to manage 64 bits at a time
is complicated because we have to pad a zero byte after each CHAR/ATTRIBUTE byte.
At least we have not tried to do it with MMX or SSE instructions, so far.
Using of PUNPCKLBW will help a lot.
Alex
Alex, If you have some spare time, post some examples with the timings
so we can see on different machines what the performances are.
You can use the example I posted, that read a file and convert it before
displaying it with WriteConsoleOutput() API.
No need to do it soon, when you are free and feel like to do it.
One missing thing in the program I posted:
ConsoleSize PROC
INVOKE AllocConsole
I deleted this line at the beginning of
ConsoleSize PROC by mistake,
it needs to be there.
Frank
Quote from: frktons on November 01, 2010, 12:28:03 AM
Alex, If you have some spare time, post some examples with the timings
so we can see on different machines what the performances are.
You can use the example I posted, that read a file and convert it before
displaying it with WriteConsoleOutput() API.
No need to do it soon, when you are free and feel like to do it.
One missing thing in the program I posted:
ConsoleSize PROC
INVOKE AllocConsole
I deleted this line at the beginning of ConsoleSize PROC by mistake,
it needs to be there.
Frank
Timings is not needed - MMX would be faster than GPR in this case, indeed.
OK.
Why do you use AllocConsole? Your testing program already has console subsystem.
Alex
Quote from: Antariy on November 01, 2010, 12:34:30 AM
Timings is not needed - MMX would be faster than GPR in this case, indeed.
OK.
Why do you use AllocConsole? Your testing program already has console subsystem.
Alex
Without that line, every time I restart the PC, if I try to run the program, it freezes and
Windows says it is trying to close it. I have to reassemble/relink it in order to have it
running again.
With
AllocConsole this doesn't happen. Maybe it is something only Win7/64 bit does. I'm not sure.
The XMM registers for PUNPCKLBW should be fine, maybe more efficient than MMX. :P
Would you like to test these different algos and display the results on this new testbed? :lol
Frank
Quote from: frktons on November 01, 2010, 12:41:49 AM
The XMM registers for PUNPCKLBW should be fine, maybe more efficient than MMX. :P
But MMX made you test-bed runnable on 3 more CPUs generations :P
And this would be unfairly - if your test-bed will be faster, than algo which it is tests :P
Quote from: frktons on November 01, 2010, 12:41:49 AM
Would you like to test these different algos and display the results on this new testbed? :lol
Hard question. Maybe... Probably... Of course :bg
Alex
Quote from: frktons on November 01, 2010, 12:41:49 AM
Without that line, every time I restart the PC, if I try to run the program, it freezes and
Windows says it is trying to close it. I have to reassemble/relink it in order to have it
running again.
With AllocConsole this doesn't happen. Maybe it is something only Win7/64 bit does. I'm not sure.
DOS - the best system :P
Alex
Quote from: Antariy on November 01, 2010, 12:46:38 AM
Quote from: frktons on November 01, 2010, 12:41:49 AM
The XMM registers for PUNPCKLBW should be fine, maybe more efficient than MMX. :P
But MMX made you test-bed runnable on 3 more CPUs generations :P
And this would be unfairly - if your test-bed will be faster, than algo which it is tests :P
Quote from: frktons on November 01, 2010, 12:41:49 AM
Would you like to test these different algos and display the results on this new testbed? :lol
Hard question. Maybe... Probably... Of course :bg
Alex
OK Alex. :U
From tomorrow I'll take care of the Row/Col to display the results, and the
ESC key to exit the program, and the "R" key to repeat the test.
Afterwhile the CPU detection code, and the remaining will be added.
You can contribute with your own code to these missing pieces as well. :P
I like DOS too. :lol I always use text screen mode like in this new project.
Now it's time to rest.
Frank
Quote from: frktons on November 01, 2010, 12:59:55 AM
You can contribute with your own code to these missing pieces as well. :P
My CPU detection is too simple - it is not currenly support some instructions set, does not make coffee and does not made weather forecast :P
Alex
Quote from: Antariy on November 01, 2010, 01:04:39 AM
My CPU detection is too simple - it is not currenly support some instructions set, does not make coffee and does not made weather forecast :P
Alex
And what about daylight saving? Does it do it? :lol
Frank
Quote from: frktons on November 01, 2010, 01:08:50 AM
And what about daylight saving? Does it do it? :lol
Yes, and it is made this with good precision - now is
-01:12 at location of the Server.
Alex
Quote from: Antariy on November 01, 2010, 01:10:32 AM
Yes, and it is made this with good precision - now is -01:12 at location of the Server.
Alex
As I suspected, it is time to go to sleep. :dazzled:
See you tomorrow with the new test bed, maybe.
:lol
Frank
Quote from: frktons on November 01, 2010, 12:41:49 AM
Without that line, every time I restart the PC, if I try to run the program, it freezes and
Windows says it is trying to close it. I have to reassemble/relink it in order to have it
running again.
Hi Frank,
It sounds like you are painting over a hole in the wall :lol.... I'd suggest you find out why this is happening or you'll likely end up chasing your tail on other issues in the future caused by this bug....
Quote from: oex on November 01, 2010, 11:07:18 AM
Hi Frank,
It sounds like you are painting over a hole in the wall :lol.... I'd suggest you find out why this is happening or you'll likely end up chasing your tail on other issues in the future caused by this bug....
I'm not sure it is a bug in the program, otherwise why should it run always fine if
I add that line? And I'm not sure it depends on some annoyance Win7 has either.
Nobody has noticed that, maybe in Win XP it doesn't happen at all. Without feed-back
from others on other systems I'm not going anywhere.
For the time being I've noticed this problem stops to pop up with this API. With some
feed-back I could find out if there are other issues involved.
The source has been posted, if anybody notices something strange please let me know.
Frank
Added some PROCs, and among them the OSVersion updated by GregL.
Changed the screen as well, and a couple of useful API to set the color
and display a string at a defined position.
Please test it and let me know how it works on your systems.
Frank
Quote from: frktons on November 01, 2010, 04:03:46 PM
Please test it and let me know how it works on your systems.
Frank, the screen of console is too big, and have scroll bars and showed partially, even if the console window have size less than desktop resolution.
Alex
Quote from: Antariy on November 01, 2010, 09:33:40 PM
Frank, the screen of console is too big, and have scroll bars and showed partially, even if the console window have size less than desktop resolution.
Alex
In the console proprieties, change the size of the font to a lesser number. I use 16 that should be enough for
1024 * 768 resolution video. Mine is 1360 * 768 so the size I can use is up to 20.
With 14 it could be visible even for lesser resolutions.
The Windows size should be 90 * 34 / the same for the buffer size. This way it should be visible without scroll bars.
What about the OS detection? Is it correct what is displayed?
Frank
Quote from: frktons on November 01, 2010, 10:00:59 PM
In the console proprieties, change the size of the font to a lesser number. I use 16 that should be enough for
........
What about the OS detection? Is it correct what is displayed?
I use 16, too, but BOLD. That is not issue of size - as sayed, window is suit to desktop resolution, just use part of it, and have scrolls.
OS detection is right.
Alex
Quote from: Antariy on November 01, 2010, 10:19:33 PM
I use 16, too, but BOLD. That is not issue of size - as sayed, window is suit to desktop resolution, just use part of it, and have scrolls.
OS detection is right.
Alex
Alex, did you check also:
Quote
The Windows size should be 90 * 34 / the same for the buffer size. This way it should be visible without scroll bars.
?
Frank
Quote from: frktons on November 01, 2010, 10:22:10 PM
Alex, did you check also:
Quote
The Windows size should be 90 * 34 / the same for the buffer size. This way it should be visible without scroll bars.
No :P
I like the standard size. Well, I can resize window manually, only for your testbed (!!! :bg), because not wanted to change defaults of console.
Alex
Quote from: Antariy on November 01, 2010, 10:33:42 PM
No :P
I like the standard size. Well, I can resize window manually, only for your testbed (!!! :bg), because not wanted to change defaults of console.
Alex
Not needed to change for all the programs, only for this one.
Frank
Quote from: frktons on November 01, 2010, 10:36:22 PM
Not needed to change for all the programs, only for this one.
Windows is remember the name of the executable, but with further testbeds - executables would have different names. So...
Alex
Quote from: Antariy on November 01, 2010, 10:39:54 PM
Windows is remember the name of the executable, but with further testbeds - executables would have different names. So...
Alex
Yes Alex, you are right. And you are able to do what needed :bg
Frank
We are approaching the final release. Here it is beta 0.20.
Please test it and let me know if anything needs to be fixed.
Frank
Quote from: frktons on November 02, 2010, 09:46:53 PM
We are approaching the final release. Here it is beta 0.20.
Please test it and let me know if anything needs to be fixed.
The place for CPU string (instructions) is not enough. Probably, string with description of the test can be showed at console title, not in console itself.
Alex
Quote from: Antariy on November 02, 2010, 10:00:19 PM
The place for CPU string (instructions) is not enough. Probably, string with description of the test can be showed at console title, not in console itself.
Alex
If I use an entire line [88 chars] like I did for the OS Version, could it be enough?
This version of CPU ID is not showing the type of supported instructions, only CPU type.
But I can use any version you can provide and I can adapt the display of the results changing
the structure of the screen display.
It would be nice to have some more feed-back about the project.
It doesn't seem there is much interest about it so far. ::)
Frank
Quote from: frktons on November 02, 2010, 10:13:57 PM
If I use an entire line [88 chars] like I did for the OS Version, could it be enough?
..........
It doesn't seem there is much interest about it so far. ::)
Probably, placing the description of the test in the Console title would be best solution - peoples know which test they are run, and no need in pointing that in the "central place".
About interest for this project: just peoples cannot believe, that you can so fastly dig into ASM, and produce this program :bg
Alex
Quote from: Antariy on November 02, 2010, 10:23:59 PM
Probably, placing the description of the test in the Console title would be best solution - peoples know which test they are run, and no need in pointing that in the "central place".
About interest for this project: just peoples cannot believe, that you can so fastly dig into ASM, and produce this program :bg
Alex
Good idea, I'll try both solutions and after I'll decide what to do. It is only beginning of november.
This New Testbed should be ready for the end of the year. :P
Well, I'm more a retired ex-professional coder than a real beginner, but in some fields we all are beginners.
In MASM and related matter I feel a very beginner. At the same time 30 years coding have left some
"attitude" hidden somewhere. :lol
Frank
Quote from: frktons on November 02, 2010, 10:47:01 PM
This New Testbed should be ready for the end of the year. :P
Well, I'm more a retired ex-professional coder than a real beginner, but in some fields we all are beginners.
In MASM and related matter I feel a very beginner. At the same time 30 years coding have left some
"attitude" hidden somewhere. :lol
I'm not joked about fast digging.
Alex
Speaking about fast digging, here it is the version with some more stuff inside
and the corrected size for displaying the strings.
Enjoy and comment, if you feel like.
Frank
Quote from: frktons on November 02, 2010, 11:11:21 PM
Speaking about fast digging, here it is the version with some more stuff inside
and the corrected size for displaying the strings.
Enjoy and comment, if you feel like.
Change the "CPU Type" to simple "CPU:" and you get place for one more instruction set name :P
That is not joke - current CPUs have such big capabilities, that 80 chars for the name and the features is not so long thing.
Reaction for keys is funny :bg
Alex
Quote from: Antariy on November 02, 2010, 11:17:06 PM
Change the "CPU Type" to simple "CPU:" and you get place for one more instruction set name :P
That is not joke - current CPUs have such big capabilities, that 80 chars for the name and the features is not so long thing.
Reaction for keys is funny :bg
Alex
As you like, here it is, I can also dedicate 2 lines if one is not enough for CPU description :P
The keys will do a lot of work:
1) Save the actual screen with results
2) View it, so people can post their zipped screen results and can be seen with the same prog
3) Repeat the test
4) Exit the program
and maybe more in the future.
Actually they just say "Here I am, what can I do for you"? :lol
Frank
Quote from: frktons on November 02, 2010, 11:26:12 PM
Actually they just say "Here I am, what can I do for you"? :lol
One coffee and one good wine :bg
Alex
For tonight this is the last modification:
I've ordered a little the display of the strings, and prepared a double line in case the CPU description
gets verbose. :lol
Frank
Quote from: frktons on November 02, 2010, 11:38:58 PM
I've ordered a little the display of the strings, and prepared a double line in case the CPU description gets verbose. :lol
Bit place for CPU - very nice :P
Good layout :U
Alex
Frank, that is simple MMX repacking of DOS-screen, and adapted CPUid code.
See for additions at start of code section.
I have leaved all funny stuff like removing not needed things (like "CpuBuffer") and debugging to you :green2
Alex
Quote from: Antariy on November 03, 2010, 09:13:56 PM
Frank, that is simple MMX repacking of DOS-screen, and adapted CPUid code.
See for additions at start of code section.
I have leaved all funny stuff like removing not needed things (like "CpuBuffer") and debugging to you :green2
Alex
Alex, the string for CPU description has a wide space to remove. See the
;invoke get_cpu_id,pbuf ; get the processor string
;mov pbuf, rv(szMonoSpace,pbuf) ; format it
to remove it.
Some variables are declared but not yet used because I have something in my
mind for the future, and the redundant code in ConvertArea was there in case
the final release get a different size screen with size not divisible by 4 or 8.
Some instructions are just leftover of experiments, and will be removed when
the program approaches its final release.
At this stage everything is changing almost everyday. Not the right time to clean
the code.
While you go on with your CPU detection routine, have a look at the
next release attached.
I've added some routines and corrected something. the V-iew key has been enabled
and the other keys are managed in a different manner. :P
Your mmx version to convert the DOS area into WIN CHAR_INFO will be used
as one of the routine to test for performance as the program will get the final
touches:
- MACRO timing
- PROC to display on the grid
- all the missing stuff.
For the time being let's use this old version that now is called
ConvertToWin.
At the end we have to test 5-6 different ways to repack the data, also with
PUNPCKLBW and maybe somebody else routines.
Frank
Frank, all things is only maded in hurry, due to you force me each day :P
Alex
Quote from: Antariy on November 03, 2010, 10:37:27 PM
Frank, all things is only maded in hurry, due to you force me each day :P
Alex
Take your time, the deadline is 31 dec 2010. No need to rush.
And if it is not ready for the end of 2010, well, no problem, it will be ready
during 2011 :lol
Frank
Strange reaction to "R" key - instead of repeating test it is shows indecently message :P
Confirm of exiting looks like "do you wanna save that data?" - probably this will stumb users into hot anger, as planned :green2
Alex
Quote from: Antariy on November 03, 2010, 10:41:42 PM
Strange reaction to "R" key - instead of repeating test it is shows indecently message :P
Confirm of exiting looks like "do you wanna save that data?" - probably this will stumb users into hot anger, as planned :green2
Alex
Everybody here is able to remove a line of code. The "R" key is not implemented yet because there
is no test to perform so far. When there will be a test, the "R" and "S" options will be ready. :lol
As planned, after this program will be around for a while, maybe somebody will express his opinion :green2
Frank
Quote from: frktons on November 03, 2010, 10:46:04 PM
Everybody here is able to remove a line of code. The "R" key is not implemented yet because there
is no test to perform so far. When there will be a test, the "R" and "S" options will be ready. :lol
As planned, after this program will be around for a while, maybe somebody will express his opinion :green2
Well,
Frank, we see that you are do big job. No needed make messageboxes which say that some feature is not implemented yet. Everybody understand this - no things is maded in a shorm moment.
About confirm I meant - familar situation: user press a key, program say "Do you really ...". User say "Yes, I'm really ...". Program say again: "I give time to you for thinking - maybe you are not want ...". User make next acknowledgement "Yes, I'm want ...". Program ask "Really?" and so on :green2
Alex
Quote from: Antariy on November 03, 2010, 10:52:01 PM
Well, Frank, we see that you are do big job. No needed make messageboxes which say that some feature is not implemented yet. Everybody understand this - no things is maded in a shorm moment.
About confirm I meant - familar situation: user press a key, program say "Do you really ...". User say "Yes, I'm really ...". Program say again: "I give time to you for thinking - maybe you are not want ...". User make next acknowledgement "Yes, I'm want ...". Program ask "Really?" and so on :green2
Alex
Sometime it can be useful. In this case the user should save the results before leaving the program, and maybe this option
gives him the opportunity to get angry or to remember he missed to do something.
It is not a problem for Windows users, because Windows is always asking to confirm replacing files, emptying the trash bin
and so on.
If the user gets annoyed of this option, he has the source code, he can just comment it or delete the line.
Or he can just press enter and he has confirmed to exit. I wouldn't bother about this in a forum of ASM programmers.
And moreover the PopBox PROC is there because of other reasons as well, that will be evident in future releases.
Frank
Quote from: frktons on November 03, 2010, 10:58:32 PM
Or he can just press enter and he has confirmed to exit. I wouldn't bother about this in a forum of ASM programmers.
If add to parameter of MessageBox
MB_DEFBUTTON2, then user would be needed to click on "Yes" button, othewise program does not exited. That is much more good to direct user into anger :bg
Jokes apart - of course, you do things which you wants - this is your project.
Alex
Quote from: Antariy on November 03, 2010, 10:52:01 PM
About confirm I meant - familar situation: user press a key, program say "Do you really ...". User say "Yes, I'm really ...". Program say again: "I give time to you for thinking - maybe you are not want ...". User make next acknowledgement "Yes, I'm want ...". Program ask "Really?" and so on :green2
Alex,
Confess that you are running Windows RG (http://www.antra.dk/winrg.swf) :dance:
Quote from: jj2007 on November 04, 2010, 12:47:13 AM
Alex,
Confess that you are running Windows RG (http://www.antra.dk/winrg.swf) :dance:
What this is? WinXP - to your notice.
Alex
Quote from: jj2007 on November 04, 2010, 12:47:13 AM
Confess that you are running Windows RG (http://www.antra.dk/winrg.swf) :dance:
No, DOS with WinXP_32s extender. :P
you have to click on his link, Alex :U
Quote from: dedndave on November 04, 2010, 01:03:45 AM
you have to click on his link, Alex :U
No, I have FlashPlayer which is not integrated into browser. I can see flash only as file - after downloading. No have gread need in seeing of monkeys tricks and jumps at any web-page.
Alex
lol well you can right-click on the link - then Save As - to run it that way, too
that way, you'll know what Windows RG is :P
(must stand for Random Generator)
Quote from: dedndave on November 04, 2010, 02:28:03 AM
lol well you can right-click on the link - then Save As - to run it that way, too
that way, you'll know what Windows RG is :P
I have made that more than hour ago :P
I have written first reply on post with link at time when I download SWF :P
Alex
Hi guys. :bg
I need your help. Before carrying on the coding of NewTestBed, I have to decide
how many algos to test and in what shape to display the results.
I attach three possibilties, that you can view with the last release posted.
[one] 12 algos tested 2 times.
[two] 24 algos tested 1 time.
[three] 12 algos tested 4 times.
What do you think about it, according to your past experiences?
Thanks
Frank
Frank, there is updates and service packs for my yesterdays' code.
Have look into comments, and at include file needed to align DOS-screen.
I have addeded not only printing of CPUs string, but return the maximal supported instructions set, too - it will be useful for checking - is support CPU that test, or not.
Alex
Quote from: Antariy on November 04, 2010, 09:18:10 PM
Frank, there is updates and service packs for my yesterdays' code.
Have look into comments, and at include file needed to align DOS-screen.
I have addeded not only printing of CPUs string, but return the maximal supported instructions set, too - it will be useful for checking - is support CPU that test, or not.
Alex
Probably it needs a new Service Pack. :lol
The last characters displayed bu your CPUID are repetitions of previous one, it looks like.
Good job by the way, carry on and we'll use it in the next release.
I've already implemented the Save Screen Function. Now I'm working on the last phase
to display the result of the tests in the grid, and I think I'll use the Third pattern posted above.
Frank
Quote from: frktons on November 04, 2010, 09:45:47 PM
The last characters displayed bu your CPUID are repetitions of previous one, it looks like.
Oh, that is because szMonoSpace removes spaces, but my CPU brand-string does not contain extra spaces. On my machile all is OK. On your - because your CPU have many spaces between "name" and numerical descriptor, szMonoSpace is *decrease* the size of the string. But I have used *initial* string length, which is returned by CPUid printing proc. So, this is reason.
So, if you replace:
shr eax,16
push eax ; prepushed value of Length for DisplayAt proc
invoke szMonoSpace,offset CpuBuffer
push eax ; buffer with CPU string
with:
mov esi,offset CpuBuffer
invoke szMonoSpace,esi
invoke lstrlen,esi
push eax
push esi
This will work. I guess, instead of returning the same pointer, which is passed to szMonoSpace, szMonoSpace should return the new string length - and things like "which is size of the string, which is computed already with easy" is not needed.
Alex
By the way, Frank - you have "jubilee" - 700 posts :lol
Quote from: Antariy on November 04, 2010, 09:55:40 PM
Oh, that is because szMonoSpace removes spaces, but my CPU brand-string does not contain extra spaces. On my machile all is OK. On your - because your CPU have many spaces between "name" and numerical descriptor, szMonoSpace is *decrease* the size of the string. But I have used *initial* string length, which is returned by CPUid printing proc. So, this is reason.
So, if you replace:
shr eax,16
push eax ; prepushed value of Length for DisplayAt proc
invoke szMonoSpace,offset CpuBuffer
push eax ; buffer with CPU string
with:
mov esi,offset CpuBuffer
invoke szMonoSpace,esi
invoke lstrlen,esi
push eax
push esi
This will work. I guess, instead of returning the same pointer, which is passed to szMonoSpace, szMonoSpace should return the new string length - and things like "which is size of the string, which is computed already with easy" is not needed.
Alex
Feel free to adjust the CPUiD code to your taste. At the end, when the routine is ready,
I'll insert it in the next release and give you credit for it in the source code.
As you can see I've a lot to do at the moment. :lol
Frank
Quote from: frktons on November 04, 2010, 10:30:25 PM
Quote from: Antariy on November 04, 2010, 09:55:40 PM
Oh, that is because szMonoSpace removes spaces, but my CPU brand-string does not contain extra spaces. On my machile all is OK. On your - because your CPU have many spaces between "name" and numerical descriptor, szMonoSpace is *decrease* the size of the string. But I have used *initial* string length, which is returned by CPUid printing proc. So, this is reason.
So, if you replace:
shr eax,16
push eax ; prepushed value of Length for DisplayAt proc
invoke szMonoSpace,offset CpuBuffer
push eax ; buffer with CPU string
with:
mov esi,offset CpuBuffer
invoke szMonoSpace,esi
invoke lstrlen,esi
push eax
push esi
This will work. I guess, instead of returning the same pointer, which is passed to szMonoSpace, szMonoSpace should return the new string length - and things like "which is size of the string, which is computed already with easy" is not needed.
Alex
Feel free to adjust the CPUiD code to your taste. At the end, when the routine is ready,
I'll insert it in the next release and give you credit for it in the source code.
As you can see I've a lot to do at the moment. :lol
Piece which is pointed is not CPUid code. This piece is in main procedure - to output CPU string.
The culprit is the szMonoSpace :P
Just find the "shr eax,16" string, and replace pointed piece with right, pointed too. I have addeded my code into your old release, so would be better if you incorporate the code yourself - otherwice we can have differences of the base code.
Alex
Quote from: frktons on November 04, 2010, 10:30:25 PM
Feel free to adjust the CPUiD code to your taste.
Current CPUid code, adapted for your test-bed, is right - it not only returns the length of the output CPU-string with all instruction sets, but return the maximal supported instr.set also.
Alex
Quote from: Antariy on November 04, 2010, 10:38:11 PM
Current CPUid code, adapted for your test-bed, is right - it not only returns the length of the output CPU-string with all instruction sets, but return the maximal supported instr.set also.
Alex
OK Alex, as I have time I'll have a look at it. That code is not mine, so I don't know exactly how it works.
I'll follow your suggestion in order to fix it. :U
Frank
Quote from: frktons on November 04, 2010, 11:24:04 AM
I attach three possibilties, that you can view with the last release posted.
[one] 12 algos tested 2 times.
[two] 24 algos tested 1 time.
[three] 12 algos tested 4 times.
What do you think about it, according to your past experiences?
Second pattern is better, probably. This is mine opinion only, of course.
Alex
Quote from: Antariy on November 04, 2010, 11:09:56 PM
Quote from: frktons on November 04, 2010, 11:24:04 AM
I attach three possibilties, that you can view with the last release posted.
[one] 12 algos tested 2 times.
[two] 24 algos tested 1 time.
[three] 12 algos tested 4 times.
What do you think about it, according to your past experiences?
Second pattern is better, probably. This is mine opinion only, of course.
Alex
That means you prefer to have a maximum of 24 algos to test at a time?
Frank
Quote from: frktons on November 05, 2010, 12:01:56 AM
That means you prefer to have a maximum of 24 algos to test at a time?
Well, at most cases that is not needed, indeed. But, sometimes, if testbed should include many algos, and it cannot do this - that would be not very great. So, better to make it with some reserve.
Alex
Quote from: Antariy on November 05, 2010, 01:17:35 AM
Well, at most cases that is not needed, indeed. But, sometimes, if testbed should include many algos, and it cannot do this - that would be not very great. So, better to make it with some reserve.
Alex
Probably the final release will have the possibility to switch between 12/24 display mode, depending on
the number of algos to test.
Actually I implemented your code, added something more, like Save function, F1 for Help Screen,
and attached the actual release.
Please refer to this one for any comment, or improvement you may think.
Note that in order to avoid this old style programming:
push eax
push esi
push 2 ; y
push 7 ; x
call DisplayAt
I've worked a bit to implement a PROC that is more readable:
INVOKE DisplayAt, 7, 2, ADDR CpuBuffer, DWORD PTR Lenght
I got it working with your code, and I prefer this new style for my personal taste.
Farnk
Quote from: frktons on November 05, 2010, 01:32:25 AM
Probably the final release will have the possibility to switch between 12/24 display mode, depending on
the number of algos to test.
Actually I implemented your code, added something more, like Save function, F1 for Help Screen,
and attached the actual release.
Please refer to this one for any comment, or improvement you may think.
Note that in order to avoid this old style programming:
I got it working with your code, and I prefer this new style for my personal taste.
Frank, change signature at post.
That is not old style programming, of you drop your look into sources which I attach to thread today, you will see that is only way to do thing which is needed as much possible effective :P
Specify the /FIXED switch with a linker. Look to resulting file size.
Alex
Quote from: frktons on November 05, 2010, 01:32:25 AM
push eax
push esi
push 2 ; y
push 7 ; x
call DisplayAt
I've worked a bit to implement a PROC that is more readable:
INVOKE DisplayAt, 7, 2, ADDR CpuBuffer, DWORD PTR Lenght
I got it working with your code, and I prefer this new style for my personal taste.
Well, my variant at least in 8 bytes smaller :lol
Remove old CPUID code.
Quote from: Antariy on November 05, 2010, 01:47:15 AM
Quote from: frktons on November 05, 2010, 01:32:25 AM
push eax
push esi
push 2 ; y
push 7 ; x
call DisplayAt
I've worked a bit to implement a PROC that is more readable:
INVOKE DisplayAt, 7, 2, ADDR CpuBuffer, DWORD PTR Lenght
I got it working with your code, and I prefer this new style for my personal taste.
Well, my variant at least in 8 bytes smaller :lol
Remove old CPUID code.
The first priority is to have a readable code, at least for me, at this point.
I'm not looking for the smallest or fastest code so far. It'll come in due time.
Loosing some nanoseconds when running a routine is a price I can afford. :lol
I'll remove all unneeded code along the way, the deadline, if any, is 31 december 2010. :P
There are still a lot of things to clean, fix, and add. :eek
By the way, did you try the new functions? Do they work correctly or there is something
to fix?
Frank
Quote from: frktons on November 05, 2010, 02:07:37 AM
The first priority is to have a readable code, at least for me, at this point.
I'm not looking for the smallest or fastest code so far. It'll come in due time.
Loosing some nanoseconds when running a routine is a price I can afford. :lol
I'll remove all unneeded code along the way, the deadline, if any, is 31 december 2010. :P
There are still a lot of things to clean, fix, and add. :eek
By the way, did you try the new functions? Do they work correctly or there is something
to fix?
Frank
It is readable,
Frank. Just if you can save some data with simple pre-pushing it (1 byte for reg), instead of moving into variable (5 bytes at least for variable at data section), and moving it back (again 5 bytes) - it is not only simpler, that is effective at any point of view.
You can do not clear any buffers if they are located at data section - this will speedy the start of the prog.
I'have tested new functions yesterday - when post them at first time. If you have look into sources, you will see that I replace your proc with mine, and test-bed work with my repacking proc :P
Quote from: frktons on November 05, 2010, 02:07:37 AM
I'm not looking for the smallest or fastest code so far. It'll come in due time.
No, you are looking for :P Why did you wants to use SSE instead MMX at 2 pages earlier :lol And you threaten me that you will test them for suitability :lol
Frank, add /FIXED switch into LINK.EXE command line, when you compile your .EXE That will decrease size of file without any optimization :lol
Many peoples use link.exe from MSVC10, but it is generate relocations by default, even if EXE based at 400000h. :P
Alex
Alex, I've added the Save Screen function, and the F1/H key for Help Screen just now, in the last release.
You have not tested them yet. I need to know if they work properly or there is something to fix.
Your routine for converting the buffer from DOS to Win has been included into the source, and I've to adapt
it to the logic of the program, that has changed since the old release you were using.
Now I use it in a general way to convert all the POP files I can read from disk, not only the main screen
that is included in precompiled data.
I Just have so many things to do, that I take my time. :lol
In the next release probably this and other things will be adapted, or added. :U
Quote from: Antariy on November 05, 2010, 02:25:42 AM
Frank, add /FIXED switch into LINK.EXE command line, when you compile your .EXE That will decrease size of file without any optimization :lol
Many people use link.exe from MSVC10, but it is generate relocations by default, even if EXE based at 400000h. :P
Alex
When the program will be almost ready, in about one month, I'll use
POLINK that is better than
MS LINK.
Now I'll try what you suggest just for curiosity. :P
Frank
Quote from: Antariy on November 05, 2010, 02:13:25 AM
I'have tested new functions yesterday - when post them at first time. If you have look into sources, you will see that I replace your proc with mine, and test-bed work with my repacking proc :P
ClearBuffer I have directly replace to MMX - don't forgot - there is computers like PIII or PI - not needed to make your test-bed not runnable on them.
Quote from: frktons on November 05, 2010, 02:30:09 AM
Alex, I've added the Save Screen function, and the F1/H key for Help Screen just now, in the last release.
You have not tested them yet. I need to know if they work properly or there is something to fix.
Your routine for converting the buffer from DOS to Win has been included into the source, and I've to adapt
it to the logic of the program, that has changed since the old release you were using.
Now I use it in a general way to convert all the POP files I can read from disk, not only the main screen
that is included in precompiled data.
I Just have so many things to do, that I take my time. :lol
In the next release probably this and other things will be adapted, or added. :U
No, I test them. They works - I have open the "help" and the variations with program, also I save the screen. All works.
Which proc did you used for saving screen into DOS-screen file? It can be written as MMX, too :lol
Alex
Quote from: Antariy on November 05, 2010, 02:30:52 AM
ClearBuffer I have directly replace to MMX - don't forgot - there is computers like PIII or PI - not needed to make your test-bed not runnable on them.
Well, I have to think a little about it. For the time being I'm oriented towards new code and new machines
But I can use the CPUID routine to switch between MMX PROC and XMM/SSSE3 ones when needed.
Quote from: Antariy on November 05, 2010, 02:35:54 AM
No, I test them. They works - I have open the "help" and the variations with program, also I save the screen. All works.
Which proc did you used for saving screen into DOS-screen file? It can be written as MMX, too :lol
Alex
The procs are: ConvertToWin and ConvertToDOS, and of course these routines can be coded in many ways,
also with MMX/SSE instructions. Actually they just use 386/486 code, I think. :lol
Frank
A new step towards the target. :bg
Enjoy it, and let me know if anything doesn't work or needs to be improved.
There are still many things to implement. Some more weeks and it'll be ready. :P
Frank
Quote from: frktons on November 08, 2010, 12:38:36 AM
Enjoy it, and let me know if anything doesn't work or needs to be improved.
In which units is measured timings?
Edited: already saw, in which. Just wonder why test is long. Repacking - one byte for less than one clock (11.718 clocks for 12240 output bytes).
Alex
Quote from: frktons on November 08, 2010, 01:05:28 AM
On my pc it takes about 6.120 CPU cycles
So - 2 bytes per clock.
Quote from: Antariy on November 08, 2010, 01:07:08 AM
Quote from: frktons on November 08, 2010, 01:05:28 AM
On my pc it takes about 6.120 CPU cycles
So - 2 bytes per clock.
Tomorrow I'll add the test for 386 code, and for
PUNPCKLBW because what we
are really doing is converting a BYTE string into a WORD string. :P
Frank
I'm actually stuck with an error during assembling probably regarding
the macro for timing:
Microsoft (R) Macro Assembler Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: K:\NewTestBed\Beta 0.60\NewTestBed.asm
K:\NewTestBed\Beta 0.60\NewTestBed.asm(671) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(674) : error A2108:use of register assumed to ERROR
counter_begin(51): Macro Called From
K:\NewTestBed\Beta 0.60\NewTestBed.asm(674): Main Line Code
K:\NewTestBed\Beta 0.60\NewTestBed.asm(676) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(684) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(703) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(723) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(732) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(744) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(750) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(768) : error A2108:use of register assumed to ERROR
K:\NewTestBed\Beta 0.60\NewTestBed.asm(772) : fatal error A1010:unmatched block nesting : Main
_
Assembly Error
Press any key to continue . . .
attached the program I'm trying to assemble.
If anybody can give me an hand looking for the error/s I'll be
glad. ::)
Frank
Frank, after this piece you addeded:
; ###########################################################################
; ---------------------------------------------------------------------------
; Second Algo to test - Uses 386 opcodes
; ---------------------------------------------------------------------------
; ###########################################################################
.data
Algo2Desc BYTE "Use 386 - Proposed by Frank",0
Algo2DescSize DWORD SIZEOF Algo2Desc
Algo2Size DWORD EndAlgo2 - Algo2
Algo2SizeStr BYTE 8 DUP (?)
PtrAlgo2SizeStr DWORD Algo2SizeStr
place tag:
.code
I.e. is needed to be:
; ###########################################################################
; ---------------------------------------------------------------------------
; Second Algo to test - Uses 386 opcodes
; ---------------------------------------------------------------------------
; ###########################################################################
.data
Algo2Desc BYTE "Use 386 - Proposed by Frank",0
Algo2DescSize DWORD SIZEOF Algo2Desc
Algo2Size DWORD EndAlgo2 - Algo2
Algo2SizeStr BYTE 8 DUP (?)
PtrAlgo2SizeStr DWORD Algo2SizeStr
.code ; <--- THIS
Alex
OK, I found it. I forget to put the .code in the second chunk of code
for II Algo to test.
Thanks Alex.
Attached new one and results.
Frank
│01 Use MMX - Proposed by Alex │ 62 │ 11.830 │ 11.703 │ 11.731 │ 11.707 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Use 386 - Proposed by Frank │ 43 │ 18.635 │ 18.765 │ 18.686 │ 18.835 ││
I guess, it is worth to make not saving of "screen", but the text-based table, with tab delims etc.
Quote from: Antariy on November 08, 2010, 02:28:11 AM
│01 Use MMX - Proposed by Alex │ 62 │ 11.830 │ 11.703 │ 11.731 │ 11.707 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Use 386 - Proposed by Frank │ 43 │ 18.635 │ 18.765 │ 18.686 │ 18.835 ││
I guess, it is worth to make not saving of "screen", but the text-based table, with tab delims etc.
I was thinking to add a Text option to save the text only. But it'll come later.
For the time being there are a lot of other things to do.
If you have time and want to do it, feel free to code a PROC to extract
the text from the result screen, ready to be written to a file or to copy to
Windows clipboard.
Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4
──────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────
Use MMX - Proposed by Alex │ 62 │ 6.961 │ 6.960 │ 6.980 │ 6.984
──────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────
Use 386 - Proposed by Frank │ 43 │ 10.234 │ 10.234 │ 10.231 │ 10.231
Frank
By the way, even now the interface is already more user friendly:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 Use MMX - Proposed by Alex │ 62 │ 7.032 │ 6.986 │ 6.982 │ 6.992 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Use 386 - Proposed by Frank │ 43 │ 10.240 │ 10.210 │ 10.225 │ 10.256 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
than previous versions used on the Forum.
Copying it into the Windows clipboard could make it even more user friendly to post
the results on the Forum. :bg
Frank
A test on another machine:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 3 (build 2600) │
│CPU : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 Use MMX - Proposed by Alex │ 62 │ 8.000 │ 8.089 │ 8.095 │ 8.132 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Use 386 - Proposed by Frank │ 43 │ 10.280 │ 10.264 │ 10.258 │ 10.256 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
Some improvements towards RC1:
ESC - exit immediately
E-Key - ask confirmation
Right Alignment of formatted numbers
Some new PROC
Some minor change in the Screen command line
Some adaptation towards Display Mode 12/24 Algos.
.....
Enjoy
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 62 │ 5.992 │ 5.988 │ 5.985 │ 5.987 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.200 │ 8.195 │ 8.237 │ 8.181 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│04 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│05 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│06 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│07 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│08 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│09 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│10 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│11 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│12 │ │ │ │ │ ││
├─────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┴┤
│ Esc Exit F1 Copy Run View Save Display 12 Help │
└────────────────────────────────────────────────────────────────────────────────────────┘
Attached new release. :eek
Frank
Quote from: frktons on November 09, 2010, 01:30:10 AM
ESC - exit immediately
E Key - ask confirmation
I guess, needed to switch keys - press Esc - ask for exit, press E - exit immediately.
Reason: if user wants to exit, and not save results - then exit must be intentional. To prove intentional exit, user must find and press E key. Because Esc is not needed to be found :bg
For what will serve Display item?
Quote from: Antariy on November 09, 2010, 01:36:59 AM
Quote from: frktons on November 09, 2010, 01:30:10 AM
ESC - exit immediately
E Key - ask confirmation
I guess, needed to switch keys - press Esc - ask for exit, press E - exit immediately.
Reason: if user wants to exit, and not save results - then exit must be intentional. To prove intentional exit, user must find and press E key. Because Esc is not needed to be found :bg
and
Quote from: Antariy on November 09, 2010, 01:38:34 AM
For what will serve Display item?
Display will switch between 12 Algos Display Mode and 24 Algos Display Mode.
It will be completed next release. :P
I've just started preparing variables, buffers, and I need to implement the logic.
It'll be the most challenging task in the program. Some days and it'll be ready.
ESC - we are used to press it to exit, and it is easy to use and find.
Many people, if any, will just copy and paste to the forum the content of the
Screen and will not bother to save the Screen with attributes, zip it and attach it.
My guess is I'll use it for my personal taste this option, and almost nobody will.
So when I want to save the Screen I have to look for the E-Key before exiting.
Just the opposite point of view, but still a good one. :lol
Frank
Quote from: frktons on November 09, 2010, 01:44:22 AM
Just the opposite point of view, but still a good one. :lol
:bg
What if integrate help-pop into the program? Just, I guess, release version must have no additional files - for being simple to using and sharing.
Quote from: Antariy on November 09, 2010, 01:48:12 AM
:bg
What if integrate help-pop into the program? Just, I guess, release version must have no additional files - for being simple to using and sharing.
Of course it will. :U
Final release will have no external file at all. :bg
Now I change it all the time, so it is not the right time to do it.
Frank
Quote from: frktons on November 09, 2010, 01:51:31 AM
Final release will have no external file at all ...
... and test-bed must be self destructable - to not mess a hard disk of the tester :P :bg
Quote from: Antariy on November 09, 2010, 01:55:55 AM
... and test-bed must be self destructable - to not mess a hard disk of the tester :P :bg
I'll see what I can do :lol
By the way, after the Display Mode 12/24 will be ready, I need to implement the Run key
and get rid of the external files. The Release 1.0 will be shipped when all these things are
ready and working fine.
After that, some improvements on the single PROCs and internal Algos of the TestBed
could or not take place, it will depend on other projects I want to develop.
Frank
Quote from: frktons on November 09, 2010, 02:11:54 AM
Quote from: Antariy on November 09, 2010, 01:55:55 AM
... and test-bed must be self destructable - to not mess a hard disk of the tester :P :bg
I'll see what I can do :lol
Be careful - do not make big bang :lol
Added XMM version of conversion from byte string to word string.
It seems like this is the most efficient way.
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 62 │ 6.276 │ 6.007 │ 5.982 │ 5.981 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.352 │ 8.382 │ 8.375 │ 8.347 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.338 │ 2.339 │ 2.338 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
Attached the newest version.
Frank
Quote from: frktons on November 09, 2010, 01:28:11 PM
Added XMM version of conversion from byte string to word string.
................
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.338 │ 2.339 │ 2.338 ││
Which clocks it have, if use MOVNTPD instead of MOVDQA?
Frank - version which is included into archive is the source of the executable included??? :eek
Alex
Quote from: Antariy on November 09, 2010, 09:32:00 PM
Quote from: frktons on November 09, 2010, 01:28:11 PM
Added XMM version of conversion from byte string to word string.
................
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.338 │ 2.339 │ 2.338 ││
EDIT:
QuoteWhich clocks it have, if use MOVNTPD instead of MOVDQA?
It is much slower on my PC at least.
Frank - version which is included into archive is the source of the executable included??? :eek
Alex
In the zip archive posted there are all the files: source, exe, inc, pop.
Which clocks it have, if use MOVNTPD instead of MOVDQA?
Frank
Quote from: frktons on November 09, 2010, 09:43:42 PM
Quote from: Antariy on November 09, 2010, 09:32:00 PM
Quote from: frktons on November 09, 2010, 01:28:11 PM
Added XMM version of conversion from byte string to word string.
................
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.338 │ 2.339 │ 2.338 ││
Which clocks it have, if use MOVNTPD instead of MOVDQA?
Frank - version which is included into archive is the source of the executable included??? :eek
Alex
In the zip archive posted there are all the files: source, exe, inc, pop.
Frank, unpack the source, compile it, and say - it is run properly?
I not see the results - they is not printed.
Also color of CPU string is not yellow, as in your EXE.
??? :eek
I don't know what's happening.
Here it is the new version with R key to rerun the test.
Now I use the new XMM version to convert the screen buffer.
Your PC should run it fine.
Frank
Quote from: frktons on November 09, 2010, 09:50:51 PM
I don't know what's happening.
Here it is the new version with R key to rerun the test.
Now I use the new XMM version to convert the screen buffer.
Your PC should run it fine.
Frank, the problem is - with SSE2 you limit your test-bed with running on old machines.
Test-bed is not thing, which is needed in insane optimization, and XMM stuff is not needed.
That is would be not great, if testbed could not run, for example - on PIII, even if the tested algos is i386...
But that is mine opinion, you do as you want, of course...
Frank, there are the same thing - test does not run! No testing results, no color changement.
Quote from: Antariy on November 09, 2010, 10:01:05 PM
Frank, the problem is - with SSE2 you limit your test-bed with running on old machines.
Test-bed is not thing, which is needed in insane optimization, and XMM stuff is not needed.
That is would be not great, if testbed could not run, for example - on PIII, even if the tested algos is i386...
But that is mine opinion, you do as you want, of course...
Frank, there are the same thing - test does not run! No testing results, no color changement.
I'm testing XMM instructions, so the program has them. The final testbed could not have them
it depends on how many people are going to use it and on what machines.
Some people have tested it without problems. And it doesn't show any problem on my machine.
What OS and CPU are you using?
Frank
Quote from: frktons on November 09, 2010, 10:05:13 PM
Some people have tested it without problems. And it doesn't show any problem on my machine.
What OS and CPU are you using?
Problem is: when I recompile your source (used ML 8.0), then resulting EXE is not perform some things. For example - color of the CPU string is white, and testing results is not showed at all.
Quote from: Antariy on November 09, 2010, 10:08:32 PM
Problem is: when I recompile your source (used ML 8.0), then resulting EXE is not perform some things. For example - color of the CPU string is white, and testing results is not showed at all.
I'm using ML 10 and Polink.
Try to change this:
CALL ConvertXmm
with:
INVOKE AlexConvertArea, ADDR FileScreen, ADDR ConsoleScreen12, NumCycles
that is your routine adapted, and see what happens.
EDIT: What happens if you run my compiled EXE? Do you have the same problems?
Frank
Quote from: frktons on November 09, 2010, 10:14:22 PM
EDIT: What happens if you run my compiled EXE? Do you have the same problems?
If I run your EXE - it works fine. That is the problem.
When I compile it with ML v.10 (you are remember :U), then it works fine, too.
But when I compile it with ML 8.0 or ML 6.15 - program was not work as must. Colors is not changed, results is not printed.
When run under debugger, I see, that "FileBuffer" is the zero memory array - it doesn't contain data of the DOS screen.
Quote from: frktons on November 09, 2010, 09:50:51 PM
I don't know what's happening.
Here it is the new version with R key to rerun the test.
Now I use the new XMM version to convert the screen buffer.
Your PC should run it fine.
Frank
Works fine on my machine, Win XP SP2 with Celeron M.
Quote from: jj2007 on November 09, 2010, 10:48:32 PM
Works fine on my machine, Win XP SP2 with Celeron M.
Any chance to see the results? :bg
Quote from: Antariy on November 09, 2010, 10:41:30 PM
If I run your EXE - it works fine. That is the problem.
When I compile it with ML v.10 (you are remember :U), then it works fine, too.
But when I compile it with ML 8.0 or ML 6.15 - program was not work as must. Colors is not changed, results is not printed.
When run under debugger, I see, that "FileBuffer" is the zero memory array - it doesn't contain data of the DOS screen.
Fast solution: use ML 10
Slow One: use your knowledge, that is wider than mine, and tell me what's happening.
Frank
Quote from: jj2007 on November 09, 2010, 10:48:32 PM
Works fine on my machine, Win XP SP2 with Celeron M.
Which version of ML did you use?
Frank, the culprit is:
you are entangle the DWORDs and WORDs:
INVOKE DisplayAt, WORD PTR AlgoColDesc, WORD PTR AlgoRow, ADDR AlgoDesc,
DWORD PTR AlgoDescSize
Fix this.
Addeded later:
I found 24 times of that mistypeing. After fixing them - results is showed. But color of CPU string - is not :P
Needed to much deeper search.
ML 10 push them as DWORD - other MLs - as WORD.
Quote from: Antariy on November 09, 2010, 10:58:05 PM
Frank, the culprit is:
you are entangle the DWORDs and WORDs:
INVOKE DisplayAt, WORD PTR AlgoColDesc, WORD PTR AlgoRow, ADDR AlgoDesc,
DWORD PTR AlgoDescSize
Fix this.
Did you try it? Does it work? Why it is working with ML 10 if it is an error?
Frank
Quote from: frktons on November 09, 2010, 11:02:44 PM
Quote from: Antariy on November 09, 2010, 10:58:05 PM
Frank, the culprit is:
you are entangle the DWORDs and WORDs:
INVOKE DisplayAt, WORD PTR AlgoColDesc, WORD PTR AlgoRow, ADDR AlgoDesc,
DWORD PTR AlgoDescSize
Fix this.
Did you try it? Does it work? Why it is working with ML 10 if it is an error?
Re-read previous post carefully :P
Quote from: Antariy on November 09, 2010, 11:06:33 PM
Re-read previous post carefully :P
Again:
QuoteDid you try it? Does it work? Why is it working with ML 10 if it is an error?
I see the DWORD and WORD are mixed, but you did not answer my questions.
Frank
Quote from: frktons on November 09, 2010, 11:09:19 PM
Quote from: Antariy on November 09, 2010, 11:06:33 PM
Re-read previous post carefully :P
I see the DWORD and WORD are mixed, but you did not answer my questions.
That is general rule: you should use machine-word sized params at least. Even if you use WORD - proc will assume that DWORD is placed into stack, and will free 4 bytes, not 2.
You should not use constructions like "push word ptr [xxx]" "invoke XXX, word ptr [xxx]" etc.
Stall stand misaligned with any further surprices...
QuoteDid you try it?
Of course, I test it.
Yes, I tried it, it works. If you re-read previous-previous :) post, then you will see, that founded 24 times of this stuff, after fixing to DWORD - tests runs and timings showed. But color of the outputted string is not changed.
Try to use DWORDs instead of BYTEs and WORDs params/args.
QuoteWhy is it working with ML 10 if it is an error?
ML 10 push them as DWORD - other MLs - as WORD.Alex
Quote from: Antariy on November 09, 2010, 10:54:17 PM
Quote from: jj2007 on November 09, 2010, 10:48:32 PM
Works fine on my machine, Win XP SP2 with Celeron M.
Which version of ML did you use?
ML 6.15 and 9.0 assemble, Jwasm throws 6*Error A2071: Label is expected
ML 6.15 shows an empty display, 9.0 fills it with timings
Quote from: jj2007 on November 09, 2010, 11:19:47 PM
ML 6.15 and 9.0 assemble, Jwasm throws 6*Error A2071: Label is expected
ML 6.15 shows an empty display, 9.0 fills it with timings
So, Frank can see, what I not joked or tried to confuse him. I just tried to help...
Jochen, ML 9.0. is change colors of the strings (OS, CPU etc) to yellow, too?
Quote from: Antariy on November 09, 2010, 11:14:40 PM
That is general rule: you should use machine-word sized params at least. Even if you use WORD - proc will assume that DWORD is placed into stack, and will free 4 bytes, not 2.
You should not use constructions like "push word ptr [xxx]" "invoke XXX, word ptr [xxx]" etc.
Stall stand misaligned with any further surprices...
QuoteDid you try it?
Of course, I test it.
Yes, I tried it, it works. If you re-read previous-previous :) post, then you will see, that founded 24 times of this stuff, after fixing to DWORD - tests runs and timings showed. But color of the outputted string is not changed.
Try to use DWORDs instead of BYTEs and WORDs params/args.
QuoteWhy is it working with ML 10 if it is an error?
ML 10 push them as DWORD - other MLs - as WORD.
Alex
As I guessed you found the problem and the solution yourself. :P
Well, I'll change all the WORD into DWORD :U so people using previous versions
can compile it without errors.
Frank
Fixed version. :bg
LOCAL sysinfo:SYSTEM_INFO
LOCAL szBuild[N16]:BYTE <----- THIS
LOCAL szBuf[128]:BYTE
size of szBuild buffer should be enlarged to 24 bytes. That is not case, but for future.
The new one is print timings, but still don't change color of the text - all text is printed as white.
Quote from: Antariy on November 09, 2010, 11:30:14 PM
LOCAL sysinfo:SYSTEM_INFO
LOCAL szBuild[N16]:BYTE <----- THIS
LOCAL szBuf[128]:BYTE
size of szBuild buffer should be enlarged to 24 bytes. That is not case, but for future.
Well, that is not code that I have written, it should be inside some MACRO I use probably.
Quote from: Antariy on November 09, 2010, 11:32:57 PM
The new one is print timings, but still don't change color of the text - all text is printed as white.
The routine for changing the colors is quite simple, maybe it uses the same BYTE or WORD stuff.
Yes:
SetColorTo PROTO ForeGroundColor:BYTE, BackGroundColor:BYTE
Frank
Frank, change these variables to:
ChosenColor dd ?
ActualColor dd ?
And make SetColorTo that:
SetColorTo PROC Fore:BYTE, Back:BYTE
xor eax, eax
mov al, Back
shl al, 4
add al, Fore
mov ChosenColor, eax
invoke SetConsoleTextAttribute, wHnd, ChosenColor
ret
SetColorTo ENDP
After that (previous post and this post changements) all works fine with ML 8.0 and 6.15
And try to use all variables as DWORDs at least. There is not economy in resources, especially under Windows, but many drawbacks if you use not DWORDs...
Alex
Results:
├─────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┬┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│01 Alex / MMX - PUNPCKLBW │ 62 │ 11.778 │ 11.725 │ 11.729 │ 11.704 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.433 │ 13.433 │ 13.590 │ 13.641 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 6.824 │ 6.789 │ 6.828 │ 6.821 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
OK :U
ReFixed. Now it should also have the corrected colors. :P
Frank
Frank, use alignment of the all buffers and DOS-screen data embedded into program. Use align 16, that would be better.
Quote from: Antariy on November 09, 2010, 11:50:17 PM
Frank, use alignment of the all buffers and DOS-screen data embedded into program. Use align 16, that would be better.
Done. :U
Now the
XMM PUNPCKLBW MOVDQA version
is even faster. :lol
Frank
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 62 │ 6.001 │ 6.005 │ 5.993 │ 6.001 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.292 │ 8.283 │ 8.307 │ 8.304 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.367 │ 2.354 │ 2.367 │ 2.369 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
:U
├─────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┬┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│01 Alex / MMX - PUNPCKLBW │ 62 │ 11.868 │ 11.801 │ 11.798 │ 11.792 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 14.160 │ 14.165 │ 14.164 │ 14.280 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.593 │ 4.589 │ 4.591 │ 4.591 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
:lol
Quote from: frktons on November 09, 2010, 11:47:24 PM
ReFixed. Now it should also have the corrected colors. :P
Frank, do you saw my two latest post on the previous page?
Frank, change the count of loops for timing macros - test too long. Tests work with buffers which is big enough, so - no needed to do many-many loops.
Quote from: Antariy on November 10, 2010, 12:04:03 AM
Frank, do you saw my two latest post on the previous page?
Frank, change the count of loops in for timing macros - test too long. Tests work with buffers which is big enough, so - no needed to do many-many loops.
Yes I saw it and I changed the
SetColorTo PROC with DWORD instead of BYTE and modified the code
to suit the changes.
The loops were 1.000 in previous versions, but the results seemed strange. So I changed to 1.000.000 and now
they look pretty stable.
By the way, it is up to the user to set the loop count to what he likes.
We are just making some experiments and we can set the loop count to whatever value we like.
What count do you suggest for these preliminary tests?
Frank
Quote from: frktons on November 10, 2010, 12:10:43 AM
What count do you suggest for these preliminary tests?
~3000
Quote from: Antariy on November 10, 2010, 12:17:19 AM
Quote from: frktons on November 10, 2010, 12:10:43 AM
What count do you suggest for these preliminary tests?
~3000
OK :U
From next version I'll set the count to a small number. :P
But I've noticed that with small numbers the results tend to change in a wide range.
Only with loop count > 100.000 the results tend to be stable.
Good Night.
Frank
it assembles fine with the modified 6.15 that i usually use
however, the CPU/OS text is white, and the results do not appear, as Alex said
i tried to assemble it with version 6.14, just to see what would happen
6.14 does not support XMM or SSE2/3
but, maybe some of the other errors give clues :P
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: NewTestBed.asm
NewTestBed.asm(1019) : error A2008: syntax error : [
NewTestBed.asm(1687) : error A2008: syntax error : [
NewTestBed.asm(1745) : error A2008: syntax error : xmm
NewTestBed.asm(1747) : error A2008: syntax error : [
now, comparing the EXE generated by ML 10 with the one generated by 6.15:
the ML615 EXE is 1024 bytes longer than the ML10 EXE
the binary comparison is attached...
Quote from: dedndave on November 10, 2010, 01:19:42 AM
it assembles fine with the modified 6.15 that i usually use
however, the CPU/OS text is white, and the results do not appear, as Alex said
i tried to assemble it with version 6.14, just to see what would happen
6.14 does not support XMM or SSE2/3
but, maybe some of the other errors give clues :P
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: NewTestBed.asm
NewTestBed.asm(1019) : error A2008: syntax error : [
NewTestBed.asm(1687) : error A2008: syntax error : [
NewTestBed.asm(1745) : error A2008: syntax error : xmm
NewTestBed.asm(1747) : error A2008: syntax error : [
now, comparing the EXE generated by ML 10 with the one generated by 6.15:
the ML615 EXE is 1024 bytes longer than the ML10 EXE
the binary comparison is attached...
The problem is fixed, Dave - 7 posts above - the new one. Initially Frank does not believe that this problem exist :lol
So, try recompile the version which is mentinioned.
Thank you for collaboration :U
Alex
that'll be $50 USD, Alex :bdg
Quote from: dedndave on November 10, 2010, 01:19:42 AM
it assembles fine with the modified 6.15 that i usually use
...........
now, comparing the EXE generated by ML 10 with the one generated by 6.15:
the ML615 EXE is 1024 bytes longer than the ML10 EXE
the binary comparison is attached...
By the way, which is modifyed in the ML? Just curious, because... Well, rules is rules :green2
Dave, did you use ML10 and LINK v.10, too?
Quote from: dedndave on November 10, 2010, 01:26:24 AM
that'll be $50 USD, Alex :bdg
Well, I have ancient MLs, too. So, I can (and done) tests myself. Thank you for the
expensive priceless help :green2
first, i use a patched version of 6.15
i got the original and the patch from Iczelion's site
the patch adds some text to the command line that i did not like
so, i re-worked the patch a bit
the 6.15 version by MS reports version 6.15.8803
my patched version reports version 6.15.8804
the patched version is available here
ML Version 6.15.8804 (patched) (http://www.4shared.com/file/-QIUp-BF/ml615.html)
as for the 10 - no - i used the one you included with your attachment as the Test10.exe
Quote from: dedndave on November 10, 2010, 01:33:54 AM
as for the 10 - no - i used the one you included with your attachment as the Test10.exe
The size of ML10+LINK10 executable is bigger, because LINK put a relocations into EXE, even if it is based on 400000h. Needed to specify /FIXED switch. And LINK.EXE v.10 without patching does not allow to set subsystem version to value less than 5.0.
actually, the ML10 version is 1 Kb smaller :bg
Quote from: dedndave on November 10, 2010, 01:40:00 AM
actually, the ML10 version is 1 Kb smaller :bg
Well, that is not have meaning. Some pages ago I sayed to Frank about this, and he uses POLINK, it seems.
well - that makes it hard to find the differences - lol
you might be able to use 6.15 and 10 to assemble
use the MS 10 linker
then compare the 2 EXE's
it might make it easy to find out what the problems are
otherwise, i'd have to read every line of code to see what is up :(
Quote from: dedndave on November 10, 2010, 01:45:23 AM
well - that makes it hard to find the differences - lol
you might be able to use 6.15 and 10 to assemble
use the MS 10 linker
then compare the 2 EXE's
it might make it easy to find out what the problems are
What you mean? If the format - then is possible to compile with ML10+LINK10 not bigger than with POLINK.
If you meant code generation - this is right - ML6.15 and ML10 differently generate code for used "push word ptr [xxx]".
But problem is solved already :lol
if you are using SSE3 instructions, that is the problem
masm version 6.15 only supports up to SSE2
Quote from: dedndave on November 10, 2010, 01:45:23 AM
otherwise, i'd have to read every line of code to see what is up :(
No, Dave, no! Not spent your time for this - no need in bothering yourself. Problem was *solved*.
Latest posted by Frank archive at previous page, is the right version.
Current code compilable right with ML6.15
it runs very slow, now :(
but, it does assemble and run correctly with 6.15
Quote from: dedndave on November 10, 2010, 01:55:27 AM
it runs very slow, now :(
What, what is? Which archive do you use? Which tested algo run slower?
you updated the link, right ?
they all run slow - meaning it takes a long time to run the tests
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with MMX, SSE1, SSE2, 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 │ 62 │ 9.724 │ 9.666 │ 9.660 │ 9.690 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.943 │ 13.953 │ 13.971 │ 14.028 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.663 │ 5.170 │ 5.418 │ 4.760 ││
did you change the loop count ?
Quote from: dedndave on November 10, 2010, 01:57:51 AM
you updated the link, right ?
they all run slow - meaning it takes a long time to run the tests
did you change the loop count ?
Ah... This - well, if you have readed previous page - you saw that I suggest to Frank decrease the counter of loops.
I have not posted archives, Dave, all archives posted by Frank. I only posted code pieces which was needed in modifying to be compilable right with ML6.15.
Yes, I have noticed that Frank increase a time of test, too. But you can ask to him about that tomorrow only.
we usually try to adjust the loop counts so that each run takes 0.5 to 1.0 seconds
The LOOP COUNT was 1.000.000 in the latest version.
I've set it to 100.000 that is fast enough and accurate enough as well. :P
If you want to rerun the test, just press the [R/r] key.
Frank
it could make a measurement and calculate a loop count variable
that way, the tests always take ~0.5 seconds
Quote from: dedndave on November 10, 2010, 04:31:40 AM
it could make a measurement and calculate a loop count variable
that way, the tests always take ~0.5 seconds
I'm not sure I understood exactly what you meant.
Could you elaborate that point in some details?
Frank
well - my initial thought was to run the code a few times and adjust the loop count so the test runs 0.5 seconds
but, a better approach might be to run another thread
in that thread, use Sleep,500
when that expires, the timer loop stops and tallies the time and iterations :P
it would require a little modification on MichaelW's timing code
Perhaps something like this:
;==============================================================================
include \masm32\include\masm32rt.inc
.686
include \masm32\macros\timers.asm
;==============================================================================
.data
loopcount dd 1000
dummy dd 0
.code
;==============================================================================
start:
;==============================================================================
L0:
shl loopcount, 1
invoke GetTickCount
push eax
mov esi, loopcount
counter_begin esi, HIGH_PRIORITY_CLASS
xchg dummy, edx
counter_end
invoke GetTickCount
pop edx
sub eax, edx
cmp eax, 500
jb L0
print "loopcount ",9
print str$(loopcount),13,10,13,10
invoke GetTickCount
push eax
mov esi, loopcount
counter_begin esi, HIGH_PRIORITY_CLASS
xchg dummy, edx
counter_end
print "actual time ",9
invoke GetTickCount
pop edx
sub eax, edx
print str$(eax),"ms",13,10,13,10
inkey "Press any key to exit..."
exit
;==============================================================================
end start
If the calibration takes too long, it may be possible to speed it up by doing something like a binary search for the loop count.
Quote from: frktons on November 10, 2010, 03:32:37 AM
The LOOP COUNT was 1.000.000 in the latest version.
I've set it to 100.000 that is fast enough and accurate enough as well. :P
This is good enough. :U
The fresh new release RC1 nearing the final release.
Managed strings for CPU description wider than 80 chars, and some
more cleanining and changing here and there.
Alex routine now is 200% faster than previous version thanks to movq
that replaced movntq :P
Frank
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 3.183 │ 3.183 │ 3.182 │ 3.180 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP OVQ │ 43 │ 8.397 │ 8.379 │ 8.368 │ 8.375 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.337 │ 2.337 │ 2.338 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Well, as I can see there is still some cleaning to do :lol
Frank
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ │ 64 │ 9.497 │ 9.646 │ 9.478 │ 9.453 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP OVQ │ 43 │ 13.957 │ 14.035 │ 13.947 │ 14.038 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.605 │ 4.668 │ 4.606 │ 4.616 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Apparently, only big cache have meaning in speed up :P
The string for Algo description was not cleared. I fixed it.
Yes Alex cache in these memory movement seems very important.
Frank
Cleaned algo description display:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 3.191 │ 3.180 │ 3.188 │ 3.192 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.361 │ 8.358 │ 8.369 │ 8.373 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.339 │ 2.337 │ 2.338 │ 2.344 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
With the first MMX algo by Alex we now have:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 3.190 │ 3.183 │ 3.180 │ 3.179 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.998 │ 9.004 │ 9.012 │ 9.006 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.345 │ 2.338 │ 2.340 │ 2.339 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 6.080 │ 5.991 │ 5.998 │ 6.007 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
:U
With the next release I'll post also this 4th test, and some improvement as well.
Enjoy
Frank
Somebody with SSE4 code CPU capable is needed for testing some routines
inside the Testbed.
If anybody own a SSE4 capable PC, please test the attached code and post the
partial screen, like the following:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3, SSSE3 │
│ │
│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 │ 3.119 │ 3.121 │ 3.117 │ 3.120 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.354 │ 8.364 │ 8.346 │ 8.347 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.337 │ 2.336 │ 2.336 │ 2.339 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 6.059 │ 6.157 │ 6.152 │ 6.065 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 8.521 │ 8.646 │ 8.521 │ 8.520 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Thanks
Frank
Frank,
The file in zip file RC1A will build but will not run on my XP SP3.
Quote from: hutch-- on November 11, 2010, 11:11:21 AM
Frank,
The file in zip file RC1A will build but will not run on my XP SP3.
Could you try to use the executable inside the zip?
Can you give me some info about the ML version as well?
I tried to make it usable also with previous versions of MASM,
but you never know...
Thanks
Frank
it runs ok here - even though my CPU does not support SSE4
oh - the one posted above doesn't, either :P
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with MMX, SSE1, SSE2, 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 │ 8.111 │ 7.890 │ 8.220 │ 9.305 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.244 │ 13.281 │ 13.640 │ 13.766 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.364 │ 4.372 │ 4.385 │ 4.383 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 9.085 │ 8.859 │ 8.790 │ 8.824 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.168 │ 13.170 │ 13.154 │ 13.200 │
Hutch - i cannot build it either
Apparently, ML 10 is required to assemble
Quote from: dedndave on November 11, 2010, 11:22:53 AM
it runs ok here - even though my CPU does not support SSE4
oh - the one posted above doesn't, either :P
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with MMX, SSE1, SSE2, 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 │ 8.111 │ 7.890 │ 8.220 │ 9.305 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.244 │ 13.281 │ 13.640 │ 13.766 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.364 │ 4.372 │ 4.385 │ 4.383 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 9.085 │ 8.859 │ 8.790 │ 8.824 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.168 │ 13.170 │ 13.154 │ 13.200 │
Apparentely you also learned how to copy and paste a text console screen :clap:
:lol :lol :lol :lol :lol :lol
Did you compile it? If yes which version of MASM did you use?
Thanks Dave anyway :U
Frank
i have copy/pasted it before - review previous posts :bg
Quote from: dedndave on November 11, 2010, 11:27:23 AM
i have copy/pasted it before - review previous posts :bg
:lol :lol :lol :lol
Of course you did :U
Frank,
Processor is a Core2 Quad running at 3 gig. OS is XP SP3.
I commented out line 591'
; invoke AxCPUid, offset CpuBuffer
and it works correctly.
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 3 (build 2600) │
│CPU : │
│ │
│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 │ 3.187 │ 3.188 │ 3.186 │ 3.190 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.395 │ 8.395 │ 8.389 │ 8.393 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 1.584 │ 1.583 │ 1.584 │ 1.581 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 5.277 │ 5.211 │ 5.195 │ 5.208 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 8.461 │ 8.443 │ 8.446 │ 8.447 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│07 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│08 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│09 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│10 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│11 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│12 │ │ │ │ │ │
├──────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┤
│ Esc Exit F1 Help Copy Run View Save Display 12 Info │
└────────────────────────────────────────────────────────────────────────────────────────┘
Thanks Steve. :U
This is what I was looking for.
Either Alex CPUID routine has some faults, or my code to translate its returned string
is buggy. We'll see. If you feel like, there is a PopBox PROC somewhere, could you
try to pop a message after the program flow is back from
invoke AxCPUid, offset CpuBuffer
in order to see if it is inside or outside the routine that we have the bug?
Frank
oddly enough, i am able to assemble the file as is with ML version 6.15 under XP sp2 :red
Quote from: dedndave on November 11, 2010, 11:46:56 AM
oddly enough, i am able to assemble the file as is with ML version 6.15 under XP sp2 :red
I changed all the instructions that were ML 10 dependent, to make it compatible with old MASM
versions as well. :P
In order to test long string CPU description I simulated it with the code that is
commented inside the source:
; -------------------------------------------------------------------------------
; Test a long Cpu description
; -------------------------------------------------------------------------------
;
; .data
;
; Temp db "Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with MMX, SSE1, SSE2, SSE3,"
; db " SSSE3, SSE4.1, SSE4.2 and some more stuff",0
;
; .code
;
; mov Lenght, len(ADDR Temp)
;
; INVOKE AssignStr, ADDR CpuBuffer, ADDR Temp,
; DWORD PTR Lenght
;
;
;
; jmp TestDisplay
;
; -------------------------------------------------------------------------------
; End of Test a long Cpu description
; -------------------------------------------------------------------------------
and with this PROC I split the long string in two shorter one, with a max of 80 bytes each:
; ----------------------------------------------------------------------------
; The Cpu Description string is splitted in two parts if Lenght > 80
; ----------------------------------------------------------------------------
SplitCpuDesc PROC
lea esi, CpuBuffer
add esi, ( MaxLenCpuDesc - One )
mov Lenght1, MaxLenCpuDesc
mov Lenght2, Zero
mov al, BYTE PTR [esi]
.WHILE ( al != "," )
dec esi
dec Lenght1
mov edi, [esi]
.ENDW
lea esi, CpuBuffer
lea edi, CpuDesc1
mov ecx, Lenght1
CopyChar1:
rep movs BYTE PTR [edi], BYTE PTR [esi]
inc esi
mov PtrCpuBuf2, esi
mov eax, ( Lenght )
sub eax, Lenght1
mov Lenght2, eax
lea edi, CpuDesc2
mov ecx, Lenght2
CopyChar2:
rep movs BYTE PTR [edi], BYTE PTR [esi]
ret
SplitCpuDesc ENDP
That means I tried to prevent that strings wider than 80 bytes could mess
the formatted display.
Alex signaled to me via PM that something is wrong with wider strings.
But I have no SSE4 machine to test, so I asked somebody to do it.
Now Alex and Me have to check where the bug is.
Frank
Frank, your beta 0.9 works correctly with the CPUID code.
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 3 (build 2600) │
│CPU : Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz with MMX, SSE1, SSE2, SSE3, SSSE3, SSE4
.1 │
│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 │ 62 │ 5.168 │ 5.158 │ 5.181 │ 5.198 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.326 │ 8.326 │ 8.328 │ 8.325 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 1.588 │ 1.585 │ 1.585 │ 1.585 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│04 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│05 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│06 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│07 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│08 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│09 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│10 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│11 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│12 │ │ │ │ │ ││
├─────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┴┤
│ Esc Exit F1 Copy Run View Save Display 12 Help │
└────────────────────────────────────────────────────────────────────────────────────────┘
OK Steve. This is a partial solution to the problem. The CPUID code works fine,
but the returned string is messed up by other code; mine :P
I'll try to fix this part as well.
Thanks for your help
Frank
Well. I used the exact string that Steve example shows, and indeed the program freezes.
With a wider one it didn't happen. Let me check why.
Frank
I think I fixed it. A leftover of a previous version of Split PROC was messing things.
Test this please. It should also compile without problems.
Frank
The display for Hutch test should be :
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz with MMX, SSE1, SSE2, SSE3, SSSE3, │
│ SSE4.1 │
│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 │ 3.117 │ 3.116 │ 3.118 │ 3.118 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 9.064 │ 9.064 │ 9.064 │ 9.063 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.336 │ 2.336 │ 2.336 │ 2.336 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 6.030 │ 6.103 │ 6.111 │ 6.112 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 8.947 │ 8.947 │ 9.087 │ 9.072 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Frank,
in order to test the CPU strings, i added a few lines :bg
shr ecx,9 ; has SSSE3
stc
adc [ebp].AxCPUid_Features.IsSSSE3,0
shr ecx,10 ; has SSE4.1
stc
adc [ebp].AxCPUid_Features.IsSSE41,0
shr ecx,1 ; has SSE4.2
stc
adc [ebp].AxCPUid_Features.IsSSE42,0
the result looks like this...
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with MMX, SSE1, SSE2, SSE3, SSSE3, SSE4.1, │
│ SSE4.2 │
│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 │ 9.413 │ 9.455 │ 9.435 │ 9.416 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.591 │ 13.604 │ 13.593 │ 13.618 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.391 │ 4.356 │ 4.384 │ 4.362 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 9.255 │ 9.343 │ 9.258 │ 9.199 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.611 │ 13.616 │ 13.587 │ 13.612 │
you could shorten things a bit
if a CPU has SSSE3 or SSE4, it also has 1, 2, 3
if a CPU has SSE3, it also has 1, 2
if a CPU has SSE2, it also has 1
SSE1 is actually just called SSE
if it has any SSE, it has MMX, but it is still nice to see that one
but, only one SSE level is needed:
SSE or SSE2 or SSE3 or SSSE3 or SSE4.1 or SSE4.2
Quote from: dedndave on November 11, 2010, 12:48:26 PM
Frank,
in order to test the CPU strings, i added a few lines :bg
shr ecx,9 ; has SSSE3
stc
adc [ebp].AxCPUid_Features.IsSSSE3,0
shr ecx,10 ; has SSE4.1
stc
adc [ebp].AxCPUid_Features.IsSSE41,0
shr ecx,1 ; has SSE4.2
stc
adc [ebp].AxCPUid_Features.IsSSE42,0
the result looks like this...
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with MMX, SSE1, SSE2, SSE3, SSSE3, SSE4.1, │
│ SSE4.2 │
│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 │ 9.413 │ 9.455 │ 9.435 │ 9.416 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.591 │ 13.604 │ 13.593 │ 13.618 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.391 │ 4.356 │ 4.384 │ 4.362 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 9.255 │ 9.343 │ 9.258 │ 9.199 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.611 │ 13.616 │ 13.587 │ 13.612 │
you could shorten things a bit
if a CPU has SSSE3 or SSE4, it also has 1, 2, 3
if a CPU has SSE3, it also has 1, 2
if a CPU has SSE2, it also has 1
SSE1 is actually just called SSE
if it has any SSE, it has MMX, but it is still nice to see that one
but, only one SSE level is needed:
SSE or SSE2 or SSE3 or SSSE3 or SSE4.1 or SSE4.2
Yes Dave, we are discussing about this with Alex via PM. We didn't arrive at a simple conclusion
though. We are considering AMD extensions as well, and probably a long string will be necessary
anyway.
Stay tuned and thanks for your suggestions.
Frank
This one works fine Frank.
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 3 (build 2600) │
│CPU : Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz with MMX, SSE1, SSE2, SSE3, SSSE3, │
│ SSE4.1 │
│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 │ 3.113 │ 3.118 │ 3.113 │ 3.114 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.347 │ 8.356 │ 8.346 │ 8.347 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 1.579 │ 1.578 │ 1.577 │ 1.577 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 5.177 │ 5.209 │ 5.177 │ 5.180 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 8.289 │ 8.283 │ 8.292 │ 8.291 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│07 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│08 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│09 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│10 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│11 │ │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│12 │ │ │ │ │ │
├──────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┤
│ Esc Exit F1 Help Copy Run View Save Display 12 Info │
└────────────────────────────────────────────────────────────────────────────────────────┘
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....
here are some...
by Tom Riddle
http://www.masm32.com/board/index.php?topic=6595.0
by Jochen
http://www.masm32.com/board/index.php?topic=10848.0
by Dave
http://www.masm32.com/board/index.php?topic=13044.0
by Hutch
http://www.masm32.com/board/index.php?topic=13837.0
CPU Frequency by Edgar and myself
http://www.masm32.com/board/index.php?topic=12010.msg91492#msg91492
corrected table by myself
http://www.4shared.com/file/WHXNrzwq/Signature.html
there are many others, too :P
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 3 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.80GHz with MMX, SSE1, SSE2, 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 │ 62 │ 12.826 │ 12.047 │ 12.675 │ 12.572 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 14.453 │ 14.160 │ 14.631 │ 14.391 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│03 Frank / XMM - PUNPCKLBW │ 44 │ 4.436 │ 4.433 │ 4.427 │ 4.431 ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│04 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│05 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│06 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│07 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│08 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│09 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│10 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│11 │ │ │ │ │ ││
├─────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┼┤
│12 │ │ │ │ │ ││
├─────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┴┤
│ Esc Exit F1 Copy Run View Save Display 12 Help │
└────────────────────────────────────────────────────────────────────────────────────────┘
GOOD LOOK with Teletype
Quote from: dedndave on November 11, 2010, 04:26:32 PM
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
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
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ 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 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Quote from: frktons on November 11, 2010, 10:52:18 PM
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
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.
Quote from: Antariy on November 11, 2010, 10:58:07 PM
I guess, it should work on Win98 and ME, too :P
I don't know that until somebody uses it on those OS.
Frank
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
Quote from: Antariy on November 11, 2010, 11:04:21 PM
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
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:
.....
; 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
: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.
Quote from: Antariy on November 12, 2010, 02:07:15 AM
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:
.....
; 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:
Quote
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
Quote from: hutch-- on November 12, 2010, 05:48:42 AM
: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
Hi Frank,
Coming over from the other posting. The new one works
fine on the PIII with Windows 2000.
QuoteWe'll see what the requests are and what is doable.
Human readable please. Some abbreviation allowed. Like
maybe?
QuoteCPU: Intel(R) Core(TM)2 Quad CPU Q???? @ 3.14 GHz with MMX, SSE 1, 2, 3, 4.1, SSSE3
QuoteI 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.
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 :
┌────────────────────────────────────────────────────────────────────────────────────────┐
│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
Under peoples pressure we are striked out all non-Intel CPUs from the History :P
Quote from: FORTRANS on November 12, 2010, 04:20:18 PM
QuoteI 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
lol - "about 2" - it is either 2, or it is something else :lol
should still reflect MMX level - MMX, 3dNow!, 3dNow!+
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz about 2 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.341 │ 7.092 │ 7.487 │ 7.171 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 14.645 │ 13.592 │ 13.673 │ 13.622 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.393 │ 4.414 │ 4.755 │ 4.449 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 9.320 │ 9.298 │ 9.447 │ 9.332 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.642 │ 13.540 │ 13.566 │ 13.554 │
Quote from: dedndave on November 12, 2010, 06:40:10 PM
lol - "about 2" - it is either 2, or it is something else :lol
should still reflect MMX level - MMX, 3dNow!, 3dNow!+
That is Russian phrase construction:
Процессор о двух ядрах,
Ружьё о двух стволах etc.
That mean not "something average" that meant - "a thing which have quantity of something" :P
AMD is not implemented - if you want - you can do that yourself :P - if you have spare time.
in English, it seems the same as "approximately 2" :lol
Quote from: dedndave on November 12, 2010, 06:50:30 PM
in English, it seems the same as "approximately 2" :lol
Well, I just do not wants to repeat the same word in the same short phrase:
Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3so - I used other word. That is the rule of the Russian language. But you can still change the sources for right rules of the your native one.
This looks right to me:
Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) and SSE3
Quote from: MichaelW on November 12, 2010, 07:15:18 PM
This looks right to me:
Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) and SSE3
Well - this one is looks very good, thanks
Michael!
Frank, can you change the text?
Just find the
%s about %u logical core(s) with %s string in the sources, and replace to
%s with %u logical core(s) and %s as Michael was suggested.
Alex
OK :U The shorter version is now fixed as per request. :P
Attached.
Frank
Quote from: frktons on November 13, 2010, 12:45:26 AM
OK :U The shorter version is now fixed as per request. :P
Results,
Frank, post results :P
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 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 │ 9.543 │ 9.513 │ 9.521 │ 9.495 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 13.889 │ 13.912 │ 13.938 │ 13.889 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 4.610 │ 4.603 │ 4.615 │ 4.601 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 11.657 │ 11.651 │ 11.668 │ 11.660 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 13.908 │ 13.926 │ 13.924 │ 13.906 │
Would be fine to test with multicore CPUs.
here you are:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
│ │
│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 │ 3.125 │ 3.121 │ 3.133 │ 3.124 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP │ 43 │ 8.370 │ 8.376 │ 8.369 │ 8.378 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA │ 44 │ 2.338 │ 2.338 │ 2.341 │ 2.338 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ │ 64 │ 6.061 │ 6.058 │ 6.081 │ 6.098 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT │ 42 │ 8.199 │ 8.548 │ 8.484 │ 8.453 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
So, what about putting the algos to test in external include files, and to change the structure of
the program in order to use them, like this:
- general includes
- flags to indicate how many algos to run:
TestAlgo1 EQU ON
TestAlgo2 EQU ON
TestAlgo3 EQU ON
------
TestAlgo12 EQU OFF
- flag to indicate if using Display Mode 12 or 24 algos
DisplayMode EQU DM12/DM24
- include of data
- include of main program flow
- conditional include of the algos to test:
IF DisplayMode = DM12
IF TestAlgo1
include M12Algo1.inc; the code to manage the algo with inside the include of the Algo1.inc code to test
ENDIF
IF TestAlgo2
include M12Algo2.inc; same as above
ENDIF
--------
IF TestAlgo12
include M12Algo12.inc; same as above
ENDIF
ENDIF
And the last part:
include ProgPROC
?
In this way to test the algos the only necessary things to do should be:
1) set ON the flag of the Algo number to test
2) write a small include Algo1.inc, Algo2.inc ..... Algo12.inc with the code to test
3) put a simple description on the same include file like:
Algo1Desc DB "Alex - MMX and PUNPCKLBW",0
And also it should be easier to manage the 12/24 Display Mode.
What do you think?
FRank
In short: now you have one line more with short CPU description - no need in SplitString and two lines.
You can put lines compactly, and needed to remove the description of the test (yes, yes :green2). So, I guess, needed to make display statical - too many things with configuration of the testbed... For example - 15 or 17 algos would be enough for almost all cases.
One more: needed to make testing of the algos as something unified - macro, or code which prepares tested proc for running, and run in between timing macros'.
For that is needed this? - for making testing unified, and for possibility of exclusion of the algos, which is not supported by CPU.
Any algo can be described with its own unified structure - code which prepare algo to run checks all needed things - and manage cases when test in not possible due any reasons.
etc.
Alex
Inclusion of the algos into external include files with unified names is a good idea
I guess - all tested code must be placed externally, ALL.
Needed to done testbed's code in the way, that allow compile code, add/remove new procs with changing only external include file of the tested algo, and, probably - common include file.
Because current test-bed is not so simple as old one - changing/addition/removing of the test would be not so funny, if made it in 60 KB source file with its own structure...
Quote from: Antariy on November 13, 2010, 01:15:46 AM
In short: now you have one line more with short CPU description - no need in SplitString and two lines.
You can put lines compactly, and needed to remove the description of the test (yes, yes :green2). So, I guess, needed to make display statical - too many things with configuration of the testbed... For example - 15 or 17 algos would be enough for almost all cases.
So you are suggesting we start again from the beginning, deciding how many algos to test,
what kind of display to use, redesign the screen format, and so on?
Well, take your time and do it by all means. :lol
I'd rather prefer to complete the project and not start again from these points. :P
Quote
One more: needed to make testing of the algos as something unified - macro, or code which prepares tested proc for running, and run in between timing macros'.
For that is needed this? - for making testing unified, and for possibility of exclusion of the algos, which is not supported by CPU.
Any algo can be described with its own unified structure - code which prepare algo to run checks all needed things - and manage cases when test in not possible due any reasons.
etc.
Alex
I am not sure I understand what you mean. Can you try to explain these concepts in other words?
Quote from: Antariy on November 13, 2010, 01:22:47 AM
Inclusion of the algos into external include files with unified names is a good idea
I guess - all tested code must be placed externally, ALL.
Needed to done testbed's code in the way, that allow compile code, add/remove new procs with changing only external include file of the tested algo, and, probably - common include file.
Because current test-bed is not so simple as old one - changing/addition/removing of the test would be not so funny, if made it in 60 KB source file with its own structure...
Yes Alex, this is the reason to have external include files, to have a simple access to the testbed. :U
Frank
Quote from: frktons on November 13, 2010, 01:26:49 AM
So you are suggesting we start again from the beginning, deciding how many algos to test,
what kind of display to use, redesign the screen format, and so on?
I'd rather prefer to complete the project and not start again from these points. :P
............
I am not sure I understand what you mean. Can you try to explain these concepts in other words?
............
Yes Alex, this is the reason to have external include files, to have a simple access to the testbed. :U
Why from beginning? No - only redesign the screen - all code already written, no many changes to do. Just other DOS-screen. OS/CPU string can be the same at the same place. Just increase console window to 40 lines (for example), or exclude something from current console layout.
I just suggest more straighforward way as more faster and robust - that is your choise what is do.
I meant that thing, which I explained in second post, and I see - you are understand it.
I just want to say, that needed make testbed unified - to not change its code, but external tested code. For this is needed some rules (I mentinioned "structure") which would be parsed by testbed to know - which things is needed to do the test.
I'm sure, my new description is the same "strange" :P
The actual screen is 34 rows and 90 cols. If we go to 15 algos to test, we arrive at 40 rows
as you suggested. Probably for wide screen, 19" or more, it should be fine to see the data
displayed. I'm not sure with smaller monitors if it is clear enough to read.
Why do you think that 24 algos mode is not viable? Are they too many or what?
And a last thing, why would you prefer to remove the description of the task?
Do you prefer to have a screen with a lot on info but that is not saying what is it
all about?
Frank
Quote from: frktons on November 13, 2010, 01:45:27 AM
The actual screen is 34 rows and 90 cols. If we go to 15 algos to test, we arrive at 40 rows
as you suggested. Probably for wide screen, 19" or more, it should be fine to see the data
displayed. I'm not sure with smaller monitors if it is clear enough to read.
Why do you think that 24 algos mode is not viable? Are they too many or what?
And a last thing, why would you prefer to remove the description of the task?
Do you prefer to have a screen with a lot on info but that is not saying what is it
all about?
Frank
1024x768 (most general of the days) would be enough for ~45 lines of the console with 16 font, I guess.
As sayed - I suggest fixed screen mode as fastest and reliablest to do. But if you wants more training - implementation of it would be good thing.
But you must remember, that the unification of the testing of the algos is not done yet - that will be much more big and interesting thing to do, than switching of the screens.
If you remove description of the task, AND PUT THAT DESCRIPTION ON THE CONSOLE TITLE (SetConsoleTitle) - that would be do the same job, but with +1 line more on the console...
Alex
Quote from: Antariy on November 13, 2010, 01:55:39 AM
1024x768 (most general of the days) would be enough for ~45 lines of the console with 16 font, I guess.
As sayed - I suggest fixed screen mode as fastest and reliablest to do. But if you wants more training - implementation of it would be good thing.
But you must remember, that the unification of the testing of the algos is not done yet - that will be much more big and interesting thing to do, than switching of the screens.
If you remove description of the task, AND PUT THAT DESCRIPTION ON THE CONSOLE TITLE (SetConsoleTitle) - that would be do the same job, but with +1 line more on the console...
Alex
In order to test a task users have to modify the description of the console title?
I'm trying to avoit it. The user should only set the flags for the Display Mode and the Algos to test
in the main program, or in an include containing those data, even better.
I'd prefer the user doesn't touch at all the main program, if possible.
Probably the best thing to do is to have the user modify only the algos include, in which
there are the data and code needed:
TestAlgo1 EQU ON
DisplayMode EQU DM12
.data
AlgoSize DWORD EndAlgo1 - Algo1
Algo1Desc DB "Alex- MMX and PUNPCKBLW",0
.code
Algo1:
; code to test
EndAlgo1:
At least this is what I'm thinking at the moment. :P
Frank
Quote from: frktons on November 13, 2010, 02:06:04 AM
In order to test a task users have to modify the description of the console title?
I'm trying to avoit it. The user should only set the flags for the Display Mode and the Algos to test
in the main program, or in an include containing those data, even better.
I'd prefer the user doesn't touch at all the main program, if possible.
Probably the best thing to do is to have the user modify only the algos include, in which
there are the data and code needed:
TestAlgo1 EQU ON
Algo1Desc DB "Alex- MMX and PUNPCKBLW",0
DisplayMode EQU DM12
.data
AlgoSize DWORD EndAlgo1 - Algo1
.code
Algo1:
; code to test
EndAlgo1:
At least this is what I'm thinking at the moment. :P
You have great case to study MASM macros' design. :U
If testbed have external files with algos, why it cannot have one *common* external file?
For example - testbed_common.inc which is contain the string like:
szTitleOfTheConsole db "The test: when Hutch will say his opinion about MemInfoMicro?",0
And testbed calls SetConsoleTitle at main code without changing of the main source.
Quote from: Antariy on November 13, 2010, 02:11:18 AM
You have great case to study MASM macros' design. :U
If testbed have external files with algos, why it cannot have one *common* external file?
For example - testbed_common.inc which is contain the string like:
szTitleOfTheConsole db "The test: when Hutch will say his opinion about MemInfoMicro?",0
And testbed calls SetConsoleTitle at main code without changing of the main source.
Yes Alex, this is doable and one of the thing I'd like to do in the next version. :U
As I said I want to avoid the user touch the main program in order to use the testbed.
Frank
For Assembly programmers the number 16 is a "magic number", so the decision has been taken :lol
The Max number of Algos to test will be 16.
In this new release, V. 1.30 some changes have taken place towards the new program structure to
allow an easy way of using the New Testbed:
1) the "task description" has been moved to the Console title, freeing a couple of lines for 1 algo.
2) the rows of the main screen are now 40, to allow the display of 16 algos
3) the "D/d" option has no future anymore :P
4) some procs have been removed because not used anymore
5) the same has happened for unused variables
6) updated the Help files with new dimension and credits
7) algos to test are in included files for easy management and
replacement
Frank
Implemented the Info key to display a screen with instructions on how to use
the Testbed to test your algos. :wink
Corrected some unaligned display and some other minor things.
I'd like to know your opinion on the usability of the program and if it is clear enough
how to use it.
Thanks.
Frank
Hi, all!
At this time Frank and I'm is before issue: which kind of management of addition of test into testbed would have better usability.
I have implemented my version of manager which:
1. You can add algos for test by simple choosing from 16 available files. At this files you should put your tested code. At the same file you can set description for your algo.
2. User can specify used instructions set - if current CPU is not support these instructions, then test will not run - instead of timings will printed "N/A".
3. Labels for code size already specified - user can use one from specified labels for piece of code, or for entire proc.
All files for addition of the code into test already exist - you just should choose your file.
First two files is used for my MMX algo and Frank's SSE2 algo. Other files is templates which can be easily used for addition if new code into test.
Read comments at AlgoX.inc for understanding how you can add your code into test and tune testbed.
So, we wait feedback for comparsion which implementation of algos addition and tuning of testbed is have better usability.
Testing on non-SSE2 capable CPUs is appreciated - in this test you will see how testbed manage not supported algos.
Alex
Hi Alex.
What have you tested? It is not displayed, or I didn't see it on the screen?
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 3.782 │ 3.702 │ 3.717 │ 3.713 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 4.488 │ 4.487 │ 4.489 │ 4.502 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
And all these lines:
03 Here can be your advertisement │ 0 │ │ │ │ │
Isn't it better not to display that stuff?
Frank
Quote from: frktons on November 15, 2010, 11:21:04 PM
Hi Alex.
What have you tested? It is not displayed, or I didn't see it on the screen?
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 3.782 │ 3.702 │ 3.717 │ 3.713 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 4.488 │ 4.487 │ 4.489 │ 4.502 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
It tested algos which convert DOS-like screen to Windows console screen buffer contents. So, current algos which is included to test. I have write descriptions that because I'm tired, sorry. You can change desctiptions as you want in corresponding AlgoX.inc file :P
Quote from: frktons on November 15, 2010, 11:21:04 PM
And all these lines:
03 Here can be your advertisement │ 0 │ │ │ │ │
Isn't it better not to display that stuff?
I guess that is very funny, I didn't know how this is looks at other side of Earth :P Something like modern television. :green2
My results:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 1 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 9.976 │ 10.101 │ 10.116 │ 10.088 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 6.873 │ 6.832 │ 6.854 │ 6.811 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┴─────────┴──────────┴──────────┴──────────┴──────────┤
│ Esc Exit Copy Run View Save Info F1 Help │
└────────────────────────────────────────────────────────────────────────────────────────┘
Alex
I corrected the XMM algo, it should be:
shr ecx,2
not:
shr ecx,1
The real results are:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 3.803 │ 3.779 │ 3.798 │ 3.786 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 46 │ 2.388 │ 2.388 │ 2.386 │ 2.408 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
That display could be funny or not, I don't know, I just like clean and clear things :P
Frank
Quote from: frktons on November 15, 2010, 11:36:26 PM
I corrected the XMM algo, it should be:
shr ecx,2
not:
shr ecx,1
The real results are:
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 3.803 │ 3.779 │ 3.798 │ 3.786 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 46 │ 2.388 │ 2.388 │ 2.386 │ 2.408 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
That display could be funny or not, I don't know, I just like clean and clear things :P
Frank, I just get already existed code - nothing is changed, only address of the output buffer in tested algo at Algo2.inc
Alex
Quote from: Antariy on November 15, 2010, 11:44:25 PM
Frank, I just get already existed code - nothing is changed, only address of the output buffer in tested algo at Algo2.inc
Alex
You used an old uncorrected code of mine. :P
Quote from: frktons on November 15, 2010, 11:36:26 PM
That display could be funny or not, I don't know, I just like clean and clear things :P
Of course it is funny :P
Maybe, with this string we can get some bucks as from selling of some secret link to some free assembler :bg
Quote from: Antariy on November 15, 2010, 11:47:50 PM
Of course it is funny :P
Maybe, with this string we can get some bucks as from selling of some secret link to some free assembler :bg
Did you read what dedndave said? He wants to cut the lines to post in order to save space
for more posts on one page. Try to read all the comments that have already been expressed. :lol
Frank
Quote from: frktons on November 15, 2010, 11:58:16 PM
Quote from: Antariy on November 15, 2010, 11:47:50 PM
Of course it is funny :P
Maybe, with this string we can get some bucks as from selling of some secret link to some free assembler :bg
Did you read what dedndave said? He wants to cut the lines to post in order to save space
for more posts on one page. Try to read all the comments that have already been expressed. :lol
First, if Dave do this hard thing, and count posts on any page - he will know that forum put 15 post on each page of the thread. Have no meaning the length of the posts. :P
At second, I use not "Select All" at console menu - but manual selection.
Even if Dave gets a full screen with not needed funny info like advertisements, he can edit that screen as I do anytime - just remove impty lines with no tests.
If use software copying to clipboard, this long string with no sense for test can be used as substring for search the end of results at long string containing all screen. After founding start of this "advertisement", you can put zero byte here and copy this buffer into clipboard. Will be copyed only true results of existed algos, and OS version and CPU.
Alex
Quote from: Antariy on November 16, 2010, 12:07:18 AM
If use software copying to clipboard, this long string with no sense for test can be used as substring for search the end of results at long string containing all screen. After founding start of this "advertisement", you can put zero byte here and copy this buffer into clipboard. Will be copyed only true results of existed algos, and OS version and CPU.
Alex
I'll implement a version of copy to clipboard that copies only the used lines, I already know
how to do it, I just hadn't enough time to code it jet.
But I'll not maintain your version, only in mine I'll do the changing. I don't want to get crazy
about other versions that I don't know enough. :lol
Whatever you think about improvements in your version is your responsibility. :U
My idea, by the way, is simpler and more efficient than looking at a string inside another string.
You'll see it. :P
Frank
Quote from: frktons on November 16, 2010, 12:17:47 AM
My idea, by the way, is simpler and more efficient than looking at a string inside another string.
You'll see it. :P
That is simpler, of course, if you do all things subsequently, but I do things unified :P Unified approach have one advantage - very simple to add algo or remove algo. No needed in conditional assembly. If testbed of subsequently kind needed to be extended - quantity of work for do this, and size of the exe will increased linearly with no need in this.
Looking for substring is not so hard - you can use max ~20 instructions for reliable searching and termination of the string, and this will be fast enough. Of course, with conditional assembly (when flags-macros specifyed) this is simpler - count of the algos known at time of compilation. But this require subsequental kind of manager...
This is only mine opinion, of course, and if your code do all things better and simpler - I'm not impose anything :U
Alex
Quote from: Antariy on November 16, 2010, 12:26:26 AM
That is simpler, of course, if you do all things subsequently, but I do things unified :P Unified approach have one advantage - very simple to add algo or remove algo. No needed in conditional assembly. If testbed of subsequently kind needed to be extended - quantity of work for do this, and size of the exe will increased linearly with no need in this.
Looking for substring is not so hard - you can use max ~20 instructions for reliable searching and termination of the string, and this will be fast enough. Of course, with conditional assembly (when flags-macros specifyed) this is simpler - count of the algos known at time of compilation. But this require subsequental kind of manager...
This is only mine opinion, of course, and if your code do all things better and simpler - I'm not impose anything :U
Alex
My algo will be simpler because I already know how many lines I've displayed when the test finishs, no need
to search for anything inside the whole, I just copy the part of the screen that I already know is filled with results. :lol
Frank
Since page changed very obligingly, this is link to my post with variation of algos manager: "http://www.masm32.com/board/index.php?topic=14871.msg125063#msg125063".
This post at previois page.
Without feedback that thing have no meaning.
Quote from: frktons on November 16, 2010, 12:32:27 AM
Quote from: Antariy on November 16, 2010, 12:26:26 AM
That is simpler, of course, if you do all things subsequently, but I do things unified :P Unified approach have one advantage - very simple to add algo or remove algo. No needed in conditional assembly. If testbed of subsequently kind needed to be extended - quantity of work for do this, and size of the exe will increased linearly with no need in this.
Looking for substring is not so hard - you can use max ~20 instructions for reliable searching and termination of the string, and this will be fast enough. Of course, with conditional assembly (when flags-macros specifyed) this is simpler - count of the algos known at time of compilation. But this require subsequental kind of manager...
This is only mine opinion, of course, and if your code do all things better and simpler - I'm not impose anything :U
Alex
My algo will be simpler because I already know how many lines I've displayed when the test finishs, no need
to search for anything inside the whole, I just copy the part of the screen that I already know is filled with results. :lol
Have a look to my quote, it contain:
Quote
Of course, with conditional assembly (when flags-macros specifyed) this is simpler - count of the algos known at time of compilation. But this require subsequental kind of manager...
:P
Searching for substring will be fast, it can be done with only some instructions of the kind which you already used for fast filling the buffer. That will be very fast, of course - runtime work slower than predefined at compile-time value, but this gives opportunity to easy extension of testbed and managing of algos. And I not see any issue if testbed spent 0.000001 of the second to find the end of the string :P At lest, Windows do this each time by any reason, and still works :green2 My manager intentionally written in way to make things of managing algos - addition/removing/tunnig of testbed in unified way. That is slower, maybe, but for extensible things like testbed that is good solution. I'm not impose it in anyway.
I have already one black stone at jug. So, this is meant that I must not spent time anymore for this manager.
Alex
Quote from: Antariy on November 16, 2010, 12:40:21 AM
:P
Searching for substring will be fast, it can be done with only some instructions of the kind which you already used for fast filling the buffer. That will be very fast, of course - runtime work slower than predefined at compile-time value, but this gives opportunity to easy extension of testbed and managing of algos. And I not see any issue if testbed spent 0.000001 of the second to find the end of the string :P At lest, Windows do this each time by any reason, and still works :green2 My manager intentionally written in way to make things of managing algos - addition/removing/tunnig of testbed in unified way. That is slower, maybe, but for extensible things like testbed that is good solution. I'm not impose it in anyway.
I have already one black stone at jug. So, this is meant that I must not spent time anymore for this manager.
Alex
Time permitting we will do everything. Just not tonight :P
Frank
Hi Alex,
Tried your version of the testbed program. Partial screen
cut & paste attached. Seems to work okay.
Regards,
Steve
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 2000 Professional Service Pack 4 (build 2195) │
│CPU : Pentium III with 1 logical core(s) with SSE1 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 7.352 │ 7.361 │ 7.349 │ 7.363 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ N/A │ N/A │ N/A │ N/A │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
The program has now these new features:
1) Display date - time of test in GMT format
2) Copy only the part of the screen that is filled with results to the clipboard
with the tags to format it as <code> already in the pasted text to the Forum
3) Simplified procedure to use it
The following code is what I have in my clipboard with the [C]opy function:
┌─────────────────────────────────────────────────────────────[16 Nov 2010 at 16 40 GMT]─┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / mmx - punpcklbw movq │ 67 │ 5.422 │ 5.410 │ 5.408 │ 5.418 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / xmm - punpcklbw movdqa │ 46 │ 2.356 │ 2.356 │ 2.356 │ 2.356 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
I'll post the new release in few days. Time is needed to adapt the algo engine Alex has
prepared. :P
Stay tuned
Frank
Quote from: frktons on November 16, 2010, 04:51:45 PM
┌─────────────────────────────────────────────────────────────[16 Nov 2010 at 16 40 GMT]─┐
Frank, why hours and minutes is not separated by ":" but space instead?
Quote from: FORTRANS on November 16, 2010, 01:10:26 PM
Hi Alex,
Tried your version of the testbed program. Partial screen
cut & paste attached. Seems to work okay.
Regards,
Steve
┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS : Microsoft Windows 2000 Professional Service Pack 4 (build 2195) │
│CPU : Pentium III with 1 logical core(s) with SSE1 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 7.352 │ 7.361 │ 7.349 │ 7.363 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ N/A │ N/A │ N/A │ N/A │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Here can be your advertisement │ 0 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Thank you for test,
Steve!
Alex
Quote from: Antariy on November 16, 2010, 10:36:12 PM
Quote from: frktons on November 16, 2010, 04:51:45 PM
┌─────────────────────────────────────────────────────────────[16 Nov 2010 at 16 40 GMT]─┐
Frank, why hours and minutes is not separated by ":" but space instead?
In my latest code the ":" separator has been added. I made this test before inserting it :P
Quote from: Antariy on November 15, 2010, 11:14:56 PM
I have implemented my version of manager which:
1. You can add algos for test by simple choosing from 16 available files. At this files you should put your tested code. At the same file you can set description for your algo.
2. User can specify used instructions set - if current CPU is not support these instructions, then test will not run - instead of timings will printed "N/A".
3. Labels for code size already specified - user can use one from specified labels for piece of code, or for entire proc.
...
Alex
Works like a charm. I don't like that I have to maximise the window by hand - I always use maximised windows for such tests, and the default size is definitely too small (not everything visible).
The lines between the tests are more confusing than helpful, the eye has to jump a lot to see the differences.
Otherwise fine work, congrats!
JJ
Quote from: jj2007 on November 17, 2010, 12:45:28 AM
I don't like that I have to maximise the window by hand - I always use maximised windows for such tests, and the default size is definitely too small (not everything visible).
The lines between the tests are more confusing than helpful, the eye has to jump a lot to see the differences.
That is question for the Frank - as main developer. If exclude separation lines (horizontal grid), then can be tested up to 32 algos with current layout. Or up to ~ 20 with standard layout (25 lines - 2 for OS and CPU, 1 for keys, and something other).
Quote from: jj2007 on November 17, 2010, 12:45:28 AM
Works like a charm. I don't like that I have to maximise the window by hand - I always use maximised windows
for such tests, and the default size is definitely too small (not everything visible).
The lines between the tests are more confusing than helpful, the eye has to jump a lot to see the differences.
Otherwise fine work, congrats!
JJ
Thanks Jochen.
I use Lucida console, size 16, and the display mode can be fixed from console properties. So no need to maximize it by hand.
If you use win xp probably you switch to full screen mode that is not available anymore from vista onwards, this also can
be fixed from console properties, but I think you already know it. I don't understand where the problem is.
Sorry for the separator lines. But for me it is the opposite. I don't like attached lines one after the other. :eek
By the way, everybody here is more expert than me, so changing the display mode is not that hard for you. :P
Moreover I don't think it is possible to set a display mode that suits the needs of all users :snooty:
Frank
Quote from: frktons on November 17, 2010, 01:06:11 AM
So no need to maximize it by hand.
Jochen, double click at console title, as in each usual dialog will maximize console to show all lines/columns.
Alex
Quote from: Antariy on November 17, 2010, 01:20:08 AM
Quote from: frktons on November 17, 2010, 01:06:11 AM
So no need to maximize it by hand.
Jochen, double click at console title, as in each usual dialog will maximize console to show all lines/columns.
I know. This is what I call "need to maximize it by hand" - and it is two mouseclicks too much.
This modified code will maximize the console window.
ConsoleSize PROC
LOCAL csbi:CONSOLE_SCREEN_BUFFER_INFO
INVOKE AllocConsole
INVOKE GetStdHandle, STD_INPUT_HANDLE
mov rHnd,eax
INVOKE GetStdHandle, STD_OUTPUT_HANDLE
mov wHnd,eax
INVOKE SetConsoleTitle, ADDR ConTitle
CALL HideTheCursor
mov windowSize.Left, Zero
;mov windowSize.Right, (MaxCols -1)
mov windowSize.Top, Zero
;mov windowSize.Bottom, (MaxRows -1)
mov bufferSize.x, MaxCols
mov bufferSize.y, MaxRows
;INVOKE SetConsoleWindowInfo, wHnd, TRUE, ADDR windowSize
INVOKE SetConsoleScreenBufferSize, wHnd, DWORD PTR bufferSize
INVOKE GetConsoleScreenBufferInfo, wHnd, ADDR csbi
mov ax, csbi.dwMaximumWindowSize.x
dec ax
mov windowSize.Right, ax
mov ax, csbi.dwMaximumWindowSize.y
dec ax
mov windowSize.Bottom, ax
INVOKE SetConsoleWindowInfo, wHnd, TRUE, ADDR windowSize
ret
ConsoleSize ENDP
Quote from: jj2007 on November 17, 2010, 08:55:53 AM
I know. This is what I call "need to maximize it by hand" - and it is two mouseclicks too much.
The lazy opinion. :lol
Quote from: MichaelW on November 17, 2010, 10:00:49 AM
This modified code will maximize the console window.
ConsoleSize PROC
LOCAL csbi:CONSOLE_SCREEN_BUFFER_INFO
INVOKE AllocConsole
INVOKE GetStdHandle, STD_INPUT_HANDLE
mov rHnd,eax
INVOKE GetStdHandle, STD_OUTPUT_HANDLE
mov wHnd,eax
INVOKE SetConsoleTitle, ADDR ConTitle
CALL HideTheCursor
mov windowSize.Left, Zero
;mov windowSize.Right, (MaxCols -1)
mov windowSize.Top, Zero
;mov windowSize.Bottom, (MaxRows -1)
mov bufferSize.x, MaxCols
mov bufferSize.y, MaxRows
;INVOKE SetConsoleWindowInfo, wHnd, TRUE, ADDR windowSize
INVOKE SetConsoleScreenBufferSize, wHnd, DWORD PTR bufferSize
INVOKE GetConsoleScreenBufferInfo, wHnd, ADDR csbi
mov ax, csbi.dwMaximumWindowSize.x
dec ax
mov windowSize.Right, ax
mov ax, csbi.dwMaximumWindowSize.y
dec ax
mov windowSize.Bottom, ax
INVOKE SetConsoleWindowInfo, wHnd, TRUE, ADDR windowSize
ret
ConsoleSize ENDP
The active opinion :U
Thanks Michael. I'll do it in order to save time/energy and mouses destruction. :lol
Frank
The final release can be downloaded here:
http://www.masm32.com/board/index.php?topic=15365.msg125449#msg125449
and in following posts. Grab one, it's free. :P
Enjoy it and let me know.
Frank
Latest release 1.51. Download from previous link.
Hi!
Since Frank allow to add the "Manager" into his latest release, here it is.
Features:
1. Easy to add/remove/change algos into testbed.
Just select empty AlgoX.inc template file, and insert your code piece or proc into it. Read comments to do things - all is simple, and you can tune testbed to show description for algo and specify minimum required instructions set.
2. Printed code size - all labels inside AlgoX.inc files already specified - for code piece, and for entire proc (uncomment which you needed).
3. Changement in code which copy contents of the screen into clipboard - some small fixes of original code and adaptations.
4. All other code is Frank's.
5. Implemented coping into clipboard.
Algos files 1 and 2 already contain two tested procs, and tuned properly for needed instructions set - so see to them as to example, and put code to them after they will not needed anymore.
Feedback is welcomed.
See what it is, how to use it, any suggestions.
EDITED: the great (un)documented feature of GetNumberFormat maked some mess. See for attachment 7 posts below :P
Alex
Results (by C key):
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 01:33 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 1 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 10 853 │ 10 908 │ 10 787 │ 10 778 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8 419 │ 8 259 │ 8 353 │ 8 451 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
:bg oh oh
it appears there are null(s) after the formatted numeric string data instead of spaces
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 02:32 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 14,437
Quote from: dedndave on November 24, 2010, 02:33:56 AM
:bg oh oh
it appears there are null(s) after the formatted numeric string data instead of spaces
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 02:32 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 14,437
In other it work? :P
Did you instert trailing CODE tag yourself, or code do this itself?
Very big sources, which entangled for looking not by developer. :P
yes - works fine otherwise
no - the clipboard had the closing code tag at that point ??
at least you have an idea where to look :P
I found culprit - GetNumberFormat is returns count of chars copied + ZERO terminator - unusual behaviour, which is not documented in my sources. :P
Will post after minute...
This if fixed version. DEC EAX added to agree with (un)documentation of GetNumberFormat :P
:U
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 02:51 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 14,096 │ 14,641 │ 14,524 │ 14,501 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8,432 │ 8,768 │ 8,637 │ 8,278 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Quote from: dedndave on November 24, 2010, 02:52:00 AM
:U
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 02:51 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 14,096 │ 14,641 │ 14,524 │ 14,501 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8,432 │ 8,768 │ 8,637 │ 8,278 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
:bg
Well, now you can try to add some code into test - this will require a much less efforts, probably. :P
Alex,
Did you update the readme.txt file with any changes?
Quote from: GregL on November 24, 2010, 03:34:11 AM
Did you update the readme.txt file with any changes?
No, I didn't. I leave translation of "cyrillic English" (http://www.masm32.com/board/index.php?topic=15365.msg126128#msg126128) to Frank :lol
Quote from: dedndave on November 24, 2010, 02:52:00 AM
:U
┌─────────────────────────────────────────────────────────────[24-Nov-2010 at 02:51 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 14,096 │ 14,641 │ 14,524 │ 14,501 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8,432 │ 8,768 │ 8,637 │ 8,278 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Back Home :P
Well, some minor adjustement and it'll be perfect.
The numbers are not right aligned as they should be. The update of Help, Info and ReadMe.txt will
come ASAP.
The correct alignment:
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Clive - IDIV and Stack │ 120 │ 2.977 │ 3.015 │ 2.960 │ 2.999 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Clive - reciprocal IMUL │ 157 │ 2.015 │ 1.996 │ 1.987 │ 2.003 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Hutch ustr$ + format algo │ 159 │ 5.686 │ 5.793 │ 5.724 │ 5.789 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
This is my test, with [C] key:
┌─────────────────────────────────────────────────────────────[27-Nov-2010 at 17:56 GMT]─┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 5.605 │ 5.926 │ 5.600 │ 5.652 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 4.567 │ 4.535 │ 4.557 │ 4.554 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
welcome home, Frank
Alex added his manager :U
Quote from: frktons on November 27, 2010, 05:08:34 PM
The numbers are not right aligned as they should be. The update of Help, Info and ReadMe.txt will
come ASAP.
This is on-fast-hand solution for the "properly aligned" numbers: :P
Frank, find in testbed.asm:
@@displaytiming:
add edi,11
INVOKE DisplayAt, edi, esi, ecx,eax
change to
@@displaytiming:
add edi,11
push edi
neg edi
lea edi,[edi+eax-8]
neg edi
INVOKE DisplayAt, edi, esi, ecx,eax
pop edi
and find this:
add esp,12
invoke DisplayAt,37,esi,offset AlgoTicksStr,eax
; print the tests
change to this:
add esp,12
lea ecx,[eax-7-37]
neg ecx
invoke DisplayAt,ecx,esi,offset AlgoTicksStr,eax
; print the tests
Use comments as reference points for search.
And you will have:
┌─────────────────────────────────────────────────────────────[28-Nov-2010 at 00:45 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 1 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 10 727 │ 10 857 │ 10 843 │ 10 871 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8 408 │ 8 344 │ 8 467 │ 8 194 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
:lol
Alex
Yes Alex, I'll have to change those lines in order to have aligned numbers. :U
I was too tired yesterday, but I'll do it ASAP. :bg
OK here it is:
┌─────────────────────────────────────────────────────────────[28-Nov-2010 at 09:03 GMT]─┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 5.361 │ 5.345 │ 5.344 │ 5.352 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 4.419 │ 4.417 │ 4.418 │ 4.416 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
A little bit better, but the code size should stay 2 cols before and be right aligned as well...
Let's see where to change it...
; print the code size; <--------------------- from here it is a bit Cyrillic ASM
xor ebp,ebp
mov eax,[AlgosSizeTable+ebx*4-4]
push eax
neg eax
sbb eax,eax
and eax,2
add AlgoRow,eax
push offset fmtu
push offset AlgoTicksStr
call wsprintf; <------ NOOOOOOOOOOOOOOOOO, you did it again. :-)
; we have a dozen conversion algo from bin to ASCII, no need
; to use this C function.
add esp,12
lea ecx,[eax-7-37]; <----------------------- What about these "Magic Numbers"?
neg ecx
invoke DisplayAt,ecx,esi,offset AlgoTicksStr,eax
Probably it is better to talk about "How to change the cols" to display code size,
and how to right align it. :bg
Frank
Quote from: frktons on November 28, 2010, 08:50:48 AM
1] call wsprintf; <------ NOOOOOOOOOOOOOOOOO, you did it again. :-)
; we have a dozen conversion algo from bin to ASCII, no need
; to use this C function.
2] lea ecx,[eax-7-37]; <----------------------- What about these "Magic Numbers"?
neg ecx
Probably it is better to talk about "How to change the cols" to display code size,
and how to right align it. :bg
1] I like independency.
2] 37 is Y position of codesize printing. 7 - width of filed for print. EAX - size of string for printing. Since EAX is positive, but needed to substract it, used negative values for coordinates, and negatiation of result after calculation.
Frank, find this:
; if you like "strange fancy methods", you can put zero instead of "1"
; here :P
if 1
add esp,8
and change "if 1" to "if 0". That would be more interesting :lol
Quote from: Antariy on November 28, 2010, 11:32:17 AM
Quote from: frktons on November 28, 2010, 08:50:48 AM
1] call wsprintf; <------ NOOOOOOOOOOOOOOOOO, you did it again. :-)
; we have a dozen conversion algo from bin to ASCII, no need
; to use this C function.
2] lea ecx,[eax-7-37]; <----------------------- What about these "Magic Numbers"?
neg ecx
Probably it is better to talk about "How to change the cols" to display code size,
and how to right align it. :bg
1] I like independency.
2] 37 is Y position of codesize printing. 7 - width of filed for print. EAX - size of string for printing. Since EAX is positive, but needed to substract it, used negative values for coordinates, and negatiation of result after calculation.
1) OK :U You have to write your own language. The total independency from somebody else's code. :lol
2) Good :U, starting position should be 35 then. What about its right alignment?
It should look like this:
┬─────────┬
│Proc Size│
┼─────────┼
│ 95 │
┼─────────┼
│ 65 │
┼─────────┼
│ 73 │
┼─────────┼
│ 120 │
┼─────────┼
│ 157 │
┼─────────┼
│ 159 │
┼─────────┼
Will it look like this?
Quote from: Antariy on November 28, 2010, 11:43:23 AM
Frank, find this:
; if you like "strange fancy methods", you can put zero instead of "1"
; here :P
if 1
add esp,8
and change "if 1" to "if 0". That would be more interesting :lol
I did it, but I did not notice any difference... ::)
Frank
Quote from: frktons on November 28, 2010, 03:48:09 PM
Quote from: Antariy on November 28, 2010, 11:43:23 AM
Frank, find this:
; if you like "strange fancy methods", you can put zero instead of "1"
; here :P
if 1
add esp,8
and change "if 1" to "if 0". That would be more interesting :lol
I did it, but I did not notice any difference... ::)
Differences is not seen. That saves ~7 bytes and clock or two :P And that's based on decision that wsprintf is wrapper to wvsprintf, so pointer to the output buffer on the stack was not changed.
Quote from: Antariy on November 28, 2010, 11:29:28 PM
Differences is not seen. That saves ~7 bytes and clock or two :P And that's based on decision that wsprintf is wrapper to wvsprintf,
so pointer to the output buffer on the stack was not changed.
We consume 200-300 cycles more with
wsprintf, but we save 1 cycle using a stack pointer. :lol :lol :eek :lol :lol
Quote from: frktons on November 28, 2010, 11:35:39 PM
Quote from: Antariy on November 28, 2010, 11:29:28 PM
Differences is not seen. That saves ~7 bytes and clock or two :P And that's based on decision that wsprintf is wrapper to wvsprintf,
so pointer to the output buffer on the stack was not changed.
We consume 200-300 cycles more with wsprintf, but we save 1 cycle using a stack pointer. :lol :lol :eek :lol :lol
Frank, when you do output to console, you do IPC to the CSRSS. That would cost millions of the cycles (or hundred of thousands)... Talking about making small not heavily looped code faster in context when you do this inside/or with heavy APIs - slightly strange.
In short, even if you will replace all regular (not strongly looped) code in testbed with 10 times faster, you will not notice even millisecond of speed-up :P
But 7 bytes of size decreasing is very big amount of data, where can be putted some new advertisement :green2
Quote from: Antariy on November 28, 2010, 11:44:04 PM
Frank, when you do output to console, you do IPC to the CSRSS. That would cost millions of the cycles (or hundred of thousands)... Talking about making small not heavily looped code faster in context when you do this inside/or with heavy APIs - slightly strange.
In short, even if you will replace all regular (not strongly looped) code in testbed with 10 times faster, you will not notice even millisecond of speed-up :P
But 7 bytes of size decreasing is very big amount of data, where can be putted some new advertisement :green2
We cannot do anything about Win API that we have to call anyway to get a display, or read a file, or anything OS related.
But if we save 7 bytes we can have more advertisement.... Oh my God, what am I saying? :dazzled:
Alex, can you post the results of three or more tests of algos that have a code size bigger than 100 bytes?
You can use the six algos of 1.51 release I posted above.
You have created a very strange version, using my 1.30 version instead of latest 1.51 version, making it impossible
for me to track all the changes I made from 1.30 to 1.51.
I cannot replace again all the code updated from 1.30 onwards. You should do it from now on. :lol
Quote from: frktons on November 28, 2010, 11:58:40 PM
1] We cannot do anything about Win API that we have to call anyway to get a display, or read a file, or anything OS related.
2] But if we save 7 bytes we can have more advertisement.... Oh my God, what am I saying? :dazzled:
3] Alex, can you post the results of three or more tests of algos that have a code size bigger than 100 bytes?
You can use the six algos of 1.51 release I posted above.
4] You have created a very strange version, using my 1.30 version instead of latest 1.51 version, making it impossible
for me to track all the changes I made from 1.30 to 1.51.
5] I cannot replace again all the code updated from 1.30 onwards. You should do it from now on. :lol
1] That is reason why you should prefer smaller code in that situations :P
2] :lol
3]
┌─────────────────────────────────────────────────────────────[29-Nov-2010 at 00:09 GMT]─┐
│OS : Microsoft Windows XP Professional Service Pack 2 (build 2600) │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 1 logical core(s) with SSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 10 778 │ 10 782 │ 10 733 │ 10 888 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 8 698 │ 8 453 │ 8 433 │ 8 513 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Here can be your advertisement │ 999 │ │ │ │ │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
4] No, I used 1.51 You should see more accurately :P I just strip "Description of the test" from main source file.
5] No, due to (4]) :P
So, in your opinion this:
┌─────────────────────────────────────────────────────────────[29-Nov-2010 at 00:11 GMT]─┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 ustrv$ + GetNumberFormat │ 95 │ 44.249 │ 44.105 │ 44.029 │ 44.111 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 udw2str + GetNumberFormat │ 65 │ 43.924 │ 43.896 │ 43.832 │ 43.951 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 wsprintf + GetNumberFormat │ 73 │ 50.304 │ 50.285 │ 50.279 │ 50.330 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Clive - IDIV and Stack │ 120 │ 3.039 │ 2.933 │ 2.983 │ 2.965 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Clive - reciprocal IMUL │ 157 │ 2.033 │ 2.046 │ 1.929 │ 2.029 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Hutch ustr$ + format algo │ 159 │ 5.630 │ 5.667 │ 5.675 │ 5.681 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
is the same as this:
┌─────────────────────────────────────────────────────────────[29-Nov-2010 at 00:11 GMT]─┐
│OS : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600) │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3 │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│ Algorithm notes │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX │ 55 │ 5.807 │ 5.361 │ 5.371 │ 5.392 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / SSE2 │ 45 │ 4.434 │ 4.432 │ 4.431 │ 4.553 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
Well, I need to learn more ASM then, I was guessing it was an old version. ::)
Quote from: frktons on November 29, 2010, 12:12:56 AM
So, in your opinion this:
is the same as this:
Well, I need to learn more ASM then, I was guessing it was an old version. ::)
Core of the testbed is 1.51. All *TESTBED'S* algos is from 1.51. I'm only make my own files for my Manager. And have no desire to insert each algo to the test, so I used
old Algo1.inc and Algo2.inc files in the
new testbed :green2 Backward compatibility :P
Quote from: Antariy on November 29, 2010, 12:28:01 AM
Core of the testbed is 1.51. All *TESTBED'S* algos is from 1.51. I'm only make my own files for my Manager. And have no desire to insert each algo to the test, so I used old Algo1.inc and Algo2.inc files in the new testbed :green2 Backward compatibility :P
Very good.
Let's see how many users will use it, and after that I'll add any update or improvement I'll see fit.
:P
Quote from: frktons on November 29, 2010, 12:34:28 AM
Quote from: Antariy on November 29, 2010, 12:28:01 AM
Core of the testbed is 1.51. All *TESTBED'S* algos is from 1.51. I'm only make my own files for my Manager. And have no desire to insert each algo to the test, so I used old Algo1.inc and Algo2.inc files in the new testbed :green2 Backward compatibility :P
Very good.
Let's see how many users will use it, and after that I'll add any update or improvement I'll see fit.
:P
Use, or not use... Almost Shakespeare :green2
That's not have meaning would be manager appreciated or not, really. I'm hope that it will annoy all users equally. :P
Quote from: Antariy on November 29, 2010, 12:41:26 AM
Use, or not use... Almost Shakespeare :green2
That's not have meaning would be manager appreciated or not, really. I'm hope that it will annoy all users equally. :P
You are probably right, but it is better to wait and see. :lol
Quote from: frktons on November 29, 2010, 12:43:03 AM
Quote from: Antariy on November 29, 2010, 12:41:26 AM
Use, or not use... Almost Shakespeare :green2
That's not have meaning would be manager appreciated or not, really. I'm hope that it will annoy all users equally. :P
You are probably right, but it is better to wait and see. :lol
I meant that it does not make meaning (for me at least) - will users use Manager or not. It's annoy me alredy :P
Quote from: Antariy on November 29, 2010, 12:48:13 AM
I meant that it does not make meaning (for me at least) - will users use Manager or not. It's annoy me alredy :P
I know this method. It is called the
Ultimate failure attitude :lol
Quote from: frktons on November 30, 2010, 01:10:22 AM
Quote from: Antariy on November 29, 2010, 12:48:13 AM
I meant that it does not make meaning (for me at least) - will users use Manager or not. It's annoy me alredy :P
I know this method. It is called the Ultimate failure attitude :lol
Not understand what you mean. I have been making it as fully workable and usable. In it's current level it is contain all core things which make it extensible and flexible. Unification and one code path. Checking for supported algos. Alginment :P. Advertisements :P. Clipboard copying implemented. Bugs are not decised.
But, what I meant: without big feedback (only copuple of the peoples) - further working on it is not interesting.
QuoteNot understand what you mean.
aren't you guys both Russian ? :bg
Quote from: Antariy on November 30, 2010, 01:18:01 AM
... what I meant: without big feedback (only copuple of the peoples) - further working on it is not interesting.
It'll be interesting if somebody starts to use it, and then gives some feed-back on usability.
But it will take weeks or months. We can be satisfied for the time being. Any further development
is possible but will depend on users feed-back, I agree with this point. :U
Maybe I am going to work for another project in the next weeks or months. :P
Quote from: dedndave on November 30, 2010, 01:20:42 AM
QuoteNot understand what you mean.
aren't you guys both Russian ? :bg
No. We are Martians.
Martians usually prefer to speak on Russian. Due to this is Red planet :P
Alex, maybe you should post the latest release, with right aligned numbers.
dang - i always thought Martians were green :red
Quote from: dedndave on November 30, 2010, 01:26:40 AM
dang - i always thought Martians were green :red
To be honest, I am Vulcanian :wink
Quote from: dedndave on November 30, 2010, 01:26:40 AM
dang - i always thought Martians were green :red
Only when they got too many beer at one time :P
(http://www.recessionwire.com/wp-content/uploads/2009/05/vulcan-greeting-150.jpg)
....may the force be with you !
Quote from: dedndave on November 30, 2010, 01:29:48 AM
(http://www.recessionwire.com/wp-content/uploads/2009/05/vulcan-greeting-150.jpg)
....may the force be with you !
:U
Dave are you ready to comment and help in the next project? It will be a little bit more
difficult than the Testbed one. :8)
i have a couple little projects going, myself :P
finding time to finish them is another subject
after i finish those, i have a list of (asm programming) areas i want to learn more about
i will probably not finish the list before i die
anyways - you might find mine interesting, too
i will want you to run some tests, of course
for yours - i am always willing to try and help :bg
Quote from: frktons on November 30, 2010, 01:26:32 AM
Alex, maybe you should post the latest release, with right aligned numbers.
Here is core of it: "http://www.masm32.com/board/index.php?topic=14871.msg126271#msg126271"
Page 19 and following - my suggestions about alignment to you. And about saving of 7 bytes for new advertisements. You are implemented they already. So, you can post you version, because it is 100% identical to "mine", which is somewhere around and needed to find it firstly :P
Quote from: dedndave on November 30, 2010, 01:33:27 AM
i have a couple little projects going, myself :P
finding time to finish them is another subject
after i finish those, i have a list of (asm programming) areas i want to learn more about
i will probably not finish the list before i die
Better not to finish, otherwise the last days could be boring. :lol
Good to know you have some projects. I'm curious and of course I'll make some tests
when needed. :U
Quote from: Antariy on November 30, 2010, 01:34:17 AM
my suggestions about alignment to you. And about saving of 7 bytes for new advertisements. You are implemented they already. So, you can post you version, because it is 100% identical to "mine", which is somewhere around and needed to find it firstly :P
OK, tomorrow I'll have a look at the last version I have with your Manager, translate some cyrillic into italian english
and afterwhile post [maybe] it. :P
For now Good Night. :wink
Quote from: frktons on November 30, 2010, 01:36:27 AM
OK, tomorrow I'll have a look at the last version I have with your Manager, translate some cyrillic into italian english
and afterwhile post [maybe] it. :P
I guess, we shoud write all comments, and make names of procedures in a mix of Russian/Italian (depend of who is author of this part of the code). Then we at least will have a big feedback about "how XXX is the TestBed!!!!!!" :green2
Here it is, the last version of Testbed, with Algo manager by Alex, and many other
things. The only missing thing is the Info screen, not yet updated. But I guess you
can live without it :P
Quote from: frktons on December 01, 2010, 05:24:58 PM
Here it is, the last version of Testbed, with Algo manager by Alex, and many other
things. The only missing thing is the Info screen, not yet updated. But I guess you
can live without it :P
Ah, oh which wonderful testbed! Especially - manager!!! :lol :lol :lol :lol :lol :lol :lol
(Who will provide feedback, if not authors :green2).
Quote from: Antariy on December 01, 2010, 11:31:04 PM
Ah, oh which wonderful testbed! Especially - manager!!! :lol :lol :lol :lol :lol :lol :lol
(Who will provide feedback, if not authors :green2).
A good thing to test with testbed could be the algo to fill the screens instead of reading a precompiled
external data. This could reduce the size by 4K, more or less, for each screen, and could be an interesting field
to explore like I did in:
http://www.masm32.com/board/index.php?topic=14734.0
Back from my next trip to Rome/London I'll have a look at it.
At the moment my mind refuses to concentrate on IT stuff. :P
it is wonderful !!!
i wonder why that guy didn't use it for GetPercent :P
Quote from: dedndave on December 01, 2010, 11:46:05 PM
it is wonderful !!!
i wonder why that guy didn't use it for GetPercent :P
You are right Dave. We have to forbid tests for algos on the forum that are not done
inside the Testbed :lol
good luck with that - lol
it seems like everyone is writing a test bed these days
Quote from: dedndave on December 01, 2010, 11:46:05 PM
it is wonderful !!!
i wonder why that guy didn't use it for GetPercent :P
Because I just grab latest Jochen's testbed, and have no desire to add each from 7 algos by myself. We are decise that end-users would do this.
For example, the writer of the some book would have desire to read all books of 1000,000 drawing? :P
well - if a company comes out with a new soda, it is good marketing to give away some free soda :bg
Quote from: dedndave on December 01, 2010, 11:56:53 PM
good luck with that - lol
it seems like everyone is writing a test bed these days
The power of emulation? :U
I am happy we started a new Testbed Era, even if it is in a confusing moment. :lol
Quote from: Antariy on December 01, 2010, 11:59:25 PM
Because I just grab latest Jochen's testbed, and have no desire to add each from 7 algos by myself.
C'mon on Alex, Frank's testbed is so incredibly user-friendly that an experienced coder like you can do it in less than an hour...
Quote from: jj2007 on December 02, 2010, 12:51:54 AM
Quote from: Antariy on December 01, 2010, 11:59:25 PM
Because I just grab latest Jochen's testbed, and have no desire to add each from 7 algos by myself.
C'mon on Alex, Frank's testbed is so incredibly user-friendly that an experienced coder like you can do it in less than an hour...
Well, it already contain not small part of that friendlyness - the manager, which not require from anyone to do translation of their code to include in testbed. I have already spent many hours, when I was trying to suggest manager :green2