A New Testbed for MASM32 Forum

[Antariy]

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

[frktons]

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:

Code Select Expand


    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:

Code Select Expand


    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

[Antariy]

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

[Antariy]

Code Select Expand


    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:

Code Select Expand


    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.

[frktons]

Code Select Expand


    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:

Code Select Expand


    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

[Antariy]

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

[Antariy]

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

[Antariy]

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

[frktons]

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

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

[Antariy]

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.

[Antariy]

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

[frktons]

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.

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

[frktons]

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

[Antariy]

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

[Antariy]

On my pc it takes about 6.120 CPU cycles

So - 2 bytes per clock.