Test of cycle-count macros for DOS

[MichaelW]

The attachment contains the counter2 macros modified for operation in a 16-bit DOS application, along with a minimal set of support components and a test app. The macros work as expected running under DOS on an AMD K5, and the run to run variation in the cycle counts is very low. Running under Windows 2000 on a P3, the run to run variation of several cycles is actually less than I expected. I encountered an unexpected problem running under Windows XP on the K5 system. The test app starts, but then it gets terminated before it displays anything, with no error message and nothing in the event logs. I traced the problem to the RDTSC instructions. If I eliminate them the test app runs to completion. I currently have no convenient method of determining if this is an XP problem or an XP + K5 problem.

Edit (after a cup of coffee):

I added CLI/STI to the macros and restored the alignments for refLabel and workLabel to what they are in the Windows macros (align 16). Now running under DOS on an AMD K5 or under Windows 2000 on a P3, over 10+ trials there were no run to run variations in the cycle counts. Attachment updated.

[sinsi]

I tried the test program, booting from a floppy into DOS and got -
empty = 0, with one 9
CtBits = 45/54
CBits = 18/27

Thanks for taking the hint  :bg
Sir, I salute you :21Gun:

[MichaelW]

Running exclusively under DOS, a CLI before the tests followed by an STI afterwards would probably eliminate some of the variation. I left this out because NTVDM will not tolerate it, but it occurs to me now that it might be possible to reliably determine when it is acceptable, and execute the CLI/STI only then.

[sinsi]

>NTVDM will not tolerate it
Do you mean it crashes? I thought the IF was a per-process thing and windows ignored it.

[MichaelW]

I'm asleep at the wheel again. Windows NT and later will not tolerate it in a Windows app, but NTVDM will in a DOS app.

[dedndave]

very cool Michael   :U
thanx again

EDIT - should make this a sticky!!

[dedndave]

Michael,
i am trying to understand the use of the codealign macro
it requires a label named code_base, yet, i see no such label in the example program
i take it this label is created by the assembler by default ?
also - will the regular assembler align not work in 16-bit ?

EDIT - oh - i found it in the macro file
the second question is still good, though - lol

one more question - aligning by 8 - is there an advantage over word-alignment of procedures in 16-bit ?

[MichaelW]

In 16-bit code using the simplified segment directives, specifying any value greater than 2 in the align directive results in:

error A2189: invalid combination with segment alignment

I could not find any way around this short of using full segment definitions, and since I didn't want to do that, and I already had the codealign macro, I used it. The macro was actually intended for specifying alignments > 16 in 32-bit code.

The code_base label has to be at offset 0 in the code segment, and since the start of the segment is in dosctr.asm it needed to be there, and putting it there is actually more convenient.

The codealign 8 ahead of the test procedures was an afterthought that I probably should have left out. The main point is to ensure that for both procedures the call instruction has the same overhead, and I would guess that in 16-bit code an align 2 would suffice for this (or not, given that changing the loop labels in the macro from align 2 to codealign 16 made a significant difference in my tests).

Do these macros work OK on your P4, and do they work running under Windows XP?

[dedndave]

oh yes - it runs fine on XP
as you know, my P4 prescott always yields oddball numbers
i do get some negative counts for the empty loop
but, considering my machine, i would say that is to be expected

15 cycles, empty
45 cycles, CtBits
52 cycles, CBits
0 cycles, empty
60 cycles, CtBits
52 cycles, CBits
-15 cycles, empty
60 cycles, CtBits
52 cycles, CBits
-7 cycles, empty
60 cycles, CtBits
52 cycles, CBits
15 cycles, empty
60 cycles, CtBits
38 cycles, CBits
-15 cycles, empty
60 cycles, CtBits
52 cycles, CBits
0 cycles, empty
60 cycles, CtBits
38 cycles, CBits
0 cycles, empty
75 cycles, CtBits
150 cycles, CBits

i don't know how to confine execution to a single core under 16-bit ntvdm
perhaps, it is already confined
i may put a keyboard pause in, then limit affinity with the task manager before running the tests

[MichaelW]

Do you have any convenient way to run the test under DOS on that system?

[Magnum]

I got this when I ran it on a floppy disk.

0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits
0 cycles, empty
50 cycles, CtBits
42 cycles, CBits

[dedndave]

sorry, Michael - this machine has no floppy drive
but, Steve N. (FORTRANS) could probably test it under DOS and WIN 3.1 (WOW) for you

[qWord]

The code_base label has to be at offset 0 in the code segment, and since the start of the segment is in dosctr.asm it needed to be there, and putting it there is actually more convenient.

I've written an similarly macro that saves such declaration (outside the macro):

Code Select Expand


IFDEF algin_zero_lbl_code
goto skip
ELSE
_TEXT SEGMENT
align_mark_code:
org 0
algin_zero_lbl_code LABEL BYTE ; pos 0 in current segment
org align_mark_code
_TEXT ENDS
_DATA SEGMENT
align_mark_data:
org 0
algin_zero_lbl_data LABEL BYTE
org align_mark_data
_DATA ENDS

ENDIF

regards, qWord

[dedndave]

org 0 ???
that works ? - lol

[qWord]

yes, 0 = the first by in current segment
(proofed with masm v6-10  :8))