Board index » delphi » TimerCount

Edmund Lau

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

TimerCount

hi, anyone who can show me how to make use of the TimerCount function in the
HELPTOOL unit to measure the execution time of a task, please help.
How to include HELPTOOL unit in the source application?
your reply would be most appreciated.
 
Heinric

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


Quote
Edmund Lau wrote in message <8caglk$u...@newton.pacific.net.sg>...
>hi, anyone who can show me how to make use of the TimerCount function in
the
>HELPTOOL unit to measure the execution time of a task, please help.
>How to include HELPTOOL unit in the source application?
>your reply would be most appreciated.

Hi
I have no idea what this HELPTOOL is but here is how to access the clock
counter.

just declare:
var
  clock:longint abolute $40:$6C;

This value will increase at a rate of 18.2 Hz tilll midnight when it resets.

Chaou
Heinrich

Check my web-site:
http://homes.arealcity.com/Heinrichshomepage/
Includes a complete TP tutoriul and more!

Dr John Stockto

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


JRS:  In article <8ckmce$lm...@ctb-nnrp1.saix.net> of Fri, 7 Apr 2000
14:54:14 seen in news:comp.lang.pascal.borland, Heinrich

Quote
<n...@worldonline.co.za> wrote:

>Edmund Lau wrote in message <8caglk$u...@newton.pacific.net.sg>...
>>hi, anyone who can show me how to make use of the TimerCount function in
>the
>>HELPTOOL unit to measure the execution time of a task, please help.
>>How to include HELPTOOL unit in the source application?
>>your reply would be most appreciated.

>Hi
>I have no idea what this HELPTOOL is but here is how to access the clock
>counter.

>just declare:
>var
>  clock:longint abolute $40:$6C;

>This value will increase at a rate of 18.2 Hz tilll midnight when it resets.

WARNING: for truly reliable code, one must ensure that $40:$6C is read
atomically, for otherwise there is an hourly risk of an hour's error.
See <URL: http://www.merlyn.demon.co.uk/pas-time.htm#Atom>.
TP & BP read longints a word at a time.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Osmo Ronkan

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


In article <6KrSu4Dp0j74E...@merlyn.demon.co.uk>,
Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:

Quote
>JRS:  In article <8ckmce$lm...@ctb-nnrp1.saix.net> of Fri, 7 Apr 2000
>14:54:14 seen in news:comp.lang.pascal.borland, Heinrich
><n...@worldonline.co.za> wrote:
...
>>just declare:
1>>var
>>  clock:longint abolute $40:$6C;

>>This value will increase at a rate of 18.2 Hz tilll midnight when it resets.

>WARNING: for truly reliable code, one must ensure that $40:$6C is read
>atomically, for otherwise there is an hourly risk of an hour's error.
>See <URL: http://www.merlyn.demon.co.uk/pas-time.htm#Atom>.
>TP & BP read longints a word at a time.

No need to mess with interrupts. One can read the vale until one gets
two same values:

Function Clock:longint;
var cl:longint;
Begin
   repeat
      cl:=meml[$40:$6c];
   until cl=meml[$40:$6c];
   clock:=cl;
End;

Osmo

Dr John Stockto

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


JRS:  In article <8cmqnu$g2...@kruuna.Helsinki.FI> of Sat, 8 Apr 2000
11:30:54 seen in news:comp.lang.pascal.borland, Osmo Ronkanen

Quote
<ronka...@cc.helsinki.fi> wrote:
>In article <6KrSu4Dp0j74E...@merlyn.demon.co.uk>,
>Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:
>>JRS:  In article <8ckmce$lm...@ctb-nnrp1.saix.net> of Fri, 7 Apr 2000
>>14:54:14 seen in news:comp.lang.pascal.borland, Heinrich
>><n...@worldonline.co.za> wrote:
>...
>>>just declare:
>1>>var
>>>  clock:longint abolute $40:$6C;

>>>This value will increase at a rate of 18.2 Hz tilll midnight when it resets.

>>WARNING: for truly reliable code, one must ensure that $40:$6C is read
>>atomically, for otherwise there is an hourly risk of an hour's error.
>>See <URL: http://www.merlyn.demon.co.uk/pas-time.htm#Atom>.
>>TP & BP read longints a word at a time.

>No need to mess with interrupts. One can read the vale until one gets
>two same values:

>Function Clock:longint;
>var cl:longint;
>Begin
>   repeat
>      cl:=meml[$40:$6c];
>   until cl=meml[$40:$6c];
>   clock:=cl;
>End;

That method of pseudo-atomic reading is also given on the page in
question, in a section linked from within #Atom, with acknowledgement to
yourself and Franz Glaser.

--
? John Stockton, Surrey, UK.  j...@merlyn.demon.co.uk   Turnpike v4.00   MIME. ?
 <URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
 <URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
 <URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

stude

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


On Sat 08 Apr 2000 02:17:21p,  In article
<8fNDLJFxe374E...@merlyn.demon.co.uk>,  j...@merlyn.demon.co.uk (Dr John

Quote
Stockton) wrote:
>JRS:  In article <8cmqnu$g2...@kruuna.Helsinki.FI> of Sat, 8 Apr 2000
>11:30:54 seen in news:comp.lang.pascal.borland, Osmo Ronkanen
><ronka...@cc.helsinki.fi> wrote:
>>In article <6KrSu4Dp0j74E...@merlyn.demon.co.uk>,
>>Dr John Stockton  <j...@merlyn.demon.co.uk> wrote:
>>>JRS:  In article <8ckmce$lm...@ctb-nnrp1.saix.net> of Fri, 7 Apr 2000
>>>14:54:14 seen in news:comp.lang.pascal.borland, Heinrich
>>><n...@worldonline.co.za> wrote:
>>...
>>>>just declare:
>>1>>var
>>>>  clock:longint abolute $40:$6C;

>>>>This value will increase at a rate of 18.2 Hz tilll midnight when it
>>>>resets.

>>>WARNING: for truly reliable code, one must ensure that $40:$6C is read
>>>atomically, for otherwise there is an hourly risk of an hour's error.
>>>See <URL: http://www.merlyn.demon.co.uk/pas-time.htm#Atom>.
>>>TP & BP read longints a word at a time.

>>No need to mess with interrupts. One can read the vale until one gets
>>two same values:

>>Function Clock:longint;
>>var cl:longint;
>>Begin
>>   repeat
>>      cl:=meml[$40:$6c];
>>   until cl=meml[$40:$6c];
>>   clock:=cl;
>>End;

Even with stack checking turned off, that function produces the
following code:

call   PROGRAM.CLOCK
push   bp
mov    bp,sp
sub    sp,0008
mov    ax,0040
push   ax
mov    di,006C
pop    es
mov    ax,es:[di]
mov    dx,es:[di+02]
mov    [bp-08],ax
mov    [bp-06],dx
mov    ax,0040
push   ax
mov    di,006C
pop    es
mov    ax,es:[di]
mov    dx,es:[di+02]
cmp    dx,[bp-06]
jne    PROGRAM.15 (0006)
cmp    ax,[bp-08]
jne    PROGRAM.15 (0006)
mov    ax,[bp-08]
mov    dx,[bp-06]
mov    [bp-04],ax
mov    [bp-02],dx
mov    ax,[bp-04]
mov    dx,[bp-02]
mov    sp,bp
pop    bp
ret

...all just to read the DWORD at $40:$6C

The following function is superior to any of the methods presented.
There is no function-call overhead.

function GetClock: longint;
Inline(
  $9C/                   {PUSHF}
  $FA/                   {CLI}
  $BE/$40/$00/           {MOV SI, $40}
  $8E/$C6/               {MOV ES, SI}
  $26/$A1/$6C/$00/       {ES MOV AX,[$6C]}
  $26/$8B/$16/$6E/$00/   {ES MOV DX,[$6E]}
  $9D);                  {POPF}

If the above isn't in the FAQ, it ought to be.

Osmo Ronkan

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


In article <8F10E12A0stud...@207.211.168.82>,

Quote
student <stud...@spam.me.not> wrote:
>On Sat 08 Apr 2000 02:17:21p,  In article
><8fNDLJFxe374E...@merlyn.demon.co.uk>,  j...@merlyn.demon.co.uk (Dr John
>Stockton) wrote:

>>JRS:  In article <8cmqnu$g2...@kruuna.Helsinki.FI> of Sat, 8 Apr 2000
>>11:30:54 seen in news:comp.lang.pascal.borland, Osmo Ronkanen
>><ronka...@cc.helsinki.fi> wrote:

>>>Function Clock:longint;
>>>var cl:longint;
>>>Begin
>>>   repeat
>>>      cl:=meml[$40:$6c];
>>>   until cl=meml[$40:$6c];
>>>   clock:=cl;
>>>End;

>Even with stack checking turned off, that function produces the
>following code:
...

>...all just to read the DWORD at $40:$6C

>The following function is superior to any of the methods presented.
>There is no function-call overhead.

>function GetClock: longint;
>Inline(
>  $9C/                   {PUSHF}
>  $FA/                   {CLI}
>  $BE/$40/$00/           {MOV SI, $40}
>  $8E/$C6/               {MOV ES, SI}
>  $26/$A1/$6C/$00/       {ES MOV AX,[$6C]}
>  $26/$8B/$16/$6E/$00/   {ES MOV DX,[$6E]}
>  $9D);                  {POPF}

Are you serious? How hurry are you to read the timer count? My code is
readable to anyone. Your code could do anything. One needs to check it
with de{*word*81} first. What if you want to convent the code to PM and use
Seg0040 instead. Which is easier to convert.

Also remember that messing with the interrupt flag is not the fastest
thing in modern systems as it is emulated.

You can use the same system with ASM also:

Function clock:longint; assembler;
         asm
         mov ax,40h
         mov es,ax
@1:      mov ax,es:[6ch]
         mov dx,es:[6eh]
         cmp ax,es:[6ch]
         jne @1
         end;

That is faster than your method, especially if one writes it with inline.

Osmo

stude

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


On Sun 09 Apr 2000 04:58:32a,  In article
<8cpgno$hp...@kruuna.Helsinki.FI>,  ronka...@cc.helsinki.fi (Osmo Ronkanen)
wrote:

Quote
>>The following function is superior to any of the methods presented.
>>There is no function-call overhead.

>>function GetClock: longint;
>>Inline(
>>  $9C/                   {PUSHF}
>>  $FA/                   {CLI}
>>  $BE/$40/$00/           {MOV SI, $40}
>>  $8E/$C6/               {MOV ES, SI}
>>  $26/$A1/$6C/$00/       {ES MOV AX,[$6C]}
>>  $26/$8B/$16/$6E/$00/   {ES MOV DX,[$6E]}
>>  $9D);                  {POPF}

>Are you serious?

Yes.  Dead serious.

Quote
>How hurry are you to read the timer count?

How slowly are you to read the timer count?

Quote
>My code is readable to anyone.

So is mine.

Quote
>Your code could do anything.

No, it can only do what it is coded to do, to wit:
read the DWORD at $40:$6c atomically.

Quote
>One needs to check it
>with de{*word*81} first.

So? check it once, put it in your code library, and use it
happily ever after.

Quote
>What if you want to convent the code to PM and use
>Seg0040 instead. Which is easier to convert.

>Also remember that messing with the interrupt flag is not the fastest
>thing in modern systems as it is emulated.

My comments apply to 16-bit DOS real mode only.

Quote

>You can use the same system with ASM also:

>Function clock:longint; assembler;
>         asm
>         mov ax,40h
>         mov es,ax
>@1:      mov ax,es:[6ch]
>         mov dx,es:[6eh]
>         cmp ax,es:[6ch]
>         jne @1
>         end;

>That is faster than your method, especially if one writes it with inline.

No, it most definitely is *not* faster than what I posted, since ASM
generates a function call.  It's easy enough to test it you want to
take issue with my claim.

But secondly, and more importantly, your code has a very {*word*193} latent bug.
Can you find it? It probably would manifest itself only once in a billion
times, except of course for Murphy's Law.  I don't put code like that in my
libraries.

Osmo Ronkan

Delphi Developer
Wed, 18 Jun 1902 08:00:00 GMT

Re:TimerCount


In article <8F11A16D9stud...@207.211.168.82>,

Quote
student <stud...@spam.me.not> wrote:
>On Sun 09 Apr 2000 04:58:32a,  In article
><8cpgno$hp...@kruuna.Helsinki.FI>,  ronka...@cc.helsinki.fi (Osmo Ronkanen)
>wrote:

>>How hurry are you to read the timer count?

>How slowly are you to read the timer count?

The issue is to produce readable code.

Quote

>>My code is readable to anyone.

>So is mine.

No, it is not. It is just numbers. (comments != code)

Quote

>>What if you want to convent the code to PM and use
>>Seg0040 instead. Which is easier to convert.

>>Also remember that messing with the interrupt flag is not the fastest
>>thing in modern systems as it is emulated.

>My comments apply to 16-bit DOS real mode only.

Why?

Quote

>>You can use the same system with ASM also:

>>Function clock:longint; assembler;
>>         asm
>>         mov ax,40h
>>         mov es,ax
>>@1:      mov ax,es:[6ch]
>>         mov dx,es:[6eh]
>>         cmp ax,es:[6ch]
>>         jne @1
>>         end;

>>That is faster than your method, especially if one writes it with inline.

>No, it most definitely is *not* faster than what I posted, since ASM
>generates a function call.

That is one cycle on Pentium. The Cli could take dozens if not hundreds.
Also you are picking the irrelevant. One could write that also with inline
code.

Quote
>  It's easy enough to test it you want to
>take issue with my claim.

>But secondly, and more importantly, your code has a very {*word*193} latent bug.
>Can you find it? It probably would manifest itself only once in a billion
>times, except of course for Murphy's Law.  I don't put code like that in my
>libraries.

What bug?

Please explain in detail. Do you mean that during midnight it could give
illegal value if a timer interrupt occurred between the reads and also
between the second read and compare and they just happened to such a value
that the low byte matches. This should be impossible, for one the whole
process would take an hour and it would require timer interrupts after
executing just one instruction.

Note that even with plain simple read with no control the chance of
error is about one in billion.

Here is how an error could occur:

The code is executed between at 23:59:50.28. The value at that moment is
$17:FFFF. Now the code reads $FFFF in AX. Then a timer interrupt occurs,
causing the value to with to $18:0000 and now DX will be $18. Then
again a timer interrupt occurs and now also a process change occurs and
the process is frozen for an hour up to 00:59:59.54. Now it does the
comparison and the low word is again $FFFF and the result will be read
as $18FFFF = 24:59:49.88. I cannot imagine how this could happen in
practice. A process does not just sleep an hour.

In anyway that can easily be fixed:

Function clock:longint; assembler;
         asm
         mov ax,40h
         mov es,ax
@1:      mov ax,es:[6ch]
         mov dx,es:[6eh]
         cmp ax,es:[6ch]
         jne @1
         cmp dx,es:[6eh]
         jne @1
         end;

Of course you could generate a theory that makes even that fail but now
the cycle would tale 24 hours. (In theory you could think the value at
6ch as random value between 0 and $ffff and value at 6eh as random value
between 0 and $18 so no number of comparisons would guarantee a match
but it is more likely that the CLI fails to operate than that.)

For 100% certainty one should check for illegal values:

Function clock:longint; assembler;
         asm
         mov ax,40h
         mov es,ax
@1:      mov ax,es:[6ch]
         mov dx,es:[6eh]
         cmp ax,es:[6ch]
         jne @1
         cmp dx,18h
         jb @2
         cmp ax,0b0h
         jae @1:
@2:
         end;

Osmo

Other Threads

1. TimerCount

2. TimerCount del API????????

3. TimerCount Question