Pentium processors and Delay() 
Author Message
 Pentium processors and Delay()

Hi everybody, I'm a very experienced TP-programmer and I have
an interesting question to ask you all :

  when programming on a 80286, 80386, 80486 I can use Delay(ms) from
  the CRT-standard-unit and all works fine.  If I use Delay(5000), then
  the program waits 5 seconds (= 5000 milliseconds).

  On the other hand, when programming on a Pentium, P6, AMD K6, etc.
  something goes wrong with the timing.  It's as if the timer goes
  three times faster than as usual.  This has the effect that if I
  use Delay(5000) the program just waits for about 1 second or so.

Has anybody an idea how this can happen (timer ticks, IRQ, ...) ?
Please mail me any suggestions (or answers).  I can be found at


Thanks anyway, Sven Maerivoet, 1990 - 1998
==========================================



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()

Quote:

> Hi everybody, I'm a very experienced TP-programmer and I have
> an interesting question to ask you all :

>   when programming on a 80286, 80386, 80486 I can use Delay(ms) from
>   the CRT-standard-unit and all works fine.  If I use Delay(5000), then
>   the program waits 5 seconds (= 5000 milliseconds).

>   On the other hand, when programming on a Pentium, P6, AMD K6, etc.
>   something goes wrong with the timing.  It's as if the timer goes
>   three times faster than as usual.  This has the effect that if I
>   use Delay(5000) the program just waits for about 1 second or so.

> Has anybody an idea how this can happen (timer ticks, IRQ, ...) ?
> Please mail me any suggestions (or answers).  I can be found at


> Thanks anyway, Sven Maerivoet, 1990 - 1998
> ==========================================

The delay procedure is a dirty procedure. It simply uses a loop. The
constant is measured at startup of the program (CRT.TPU unit). Since the
Pentium processor has a feature named jump prediction, it behalves
different in the measuring routine and in the Delay(nnn) routines. This
is why the times are no longer accurate.

The CRT delay measuring procedure will totally fail on Pentium II

Quote:
>200MHz processors.

http://www.geocities.com/SiliconValley/2926/tp.html
will lead you to more details about this.

Regards,
Franz Glaser
http://members.eunet.at/meg-glaser



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()



:The delay procedure is a dirty procedure. It simply uses a loop. The
:constant is measured at startup of the program (CRT.TPU unit). Since the
:Pentium processor has a feature named jump prediction, it behalves
:different in the measuring routine and in the Delay(nnn) routines. This
:is why the times are no longer accurate.

That is also why it is advisable to substitute the Delay procedure
with the difference between two times. This works well if the needed
delay is not very short. The "Wait" procedure is given (where else)
in

 135915 Mar 6 1998 ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip
 tsfaqp.zip Common Turbo Pascal Questions and Timo's answers

   All the best, Timo

....................................................................

Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()



Quote:
> The delay procedure is a dirty procedure. It simply uses a loop. The
> constant is measured at startup of the program (CRT.TPU unit). Since the
> Pentium processor has a feature named jump prediction, it behalves
> different in the measuring routine and in the Delay(nnn) routines. This
> is why the times are no longer accurate.

Sorry, but this explanation is not quite right. Since the measuring and
the Delay use the same loop (not only the same statements, but the very
same code), the jump prediction will behave the same way in both.

The real reason for the inaccurate delay times in TP<=6 on a >=486/30
is simply an undetected integer overflow and truncation.

Quote:
> The CRT delay measuring procedure will totally fail on Pentium II
> >200MHz processors.
> http://www.geocities.com/SiliconValley/2926/tp.html
> will lead you to more details about this.

That's a different bug which is present in TP/BP 7.0. It cures the TP<=6
overflow, but at the cost of a division overflow on computers 55 times
as fast, i.e. P II/200.

John Stockton's page <http://www.merlyn.demon.co.uk/pascal.htm> contains
a more detailed discussion of the two problems. You might want to add to
your page a link to John's page, and possibly also to my NewDelay patch
at <http://fjf.gnu.de/programs.html#NewDelay>.

BTW, to everyone who's linked my pages: my pages are moving.
The URLs at www.mi.uni-erlangen.de will stop being valid within some
weeks. The new main URLs are now <http://fjf.gnu.de/> and
<http://fjf.gnu.de/programs.html>.

The provider independent URLs <http://home.pages.de/~fjf/links.html> and
<http://home.pages.de/~fjf/programs.html> will still work (but preferably
with a .html extension rather than .htm).

Frank

--

Internet links:  http://fjf.gnu.de/
Pascal programs: http://fjf.gnu.de/programs.html
PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()



Quote:
> ...
>That's a different bug which is present in TP/BP 7.0. It cures the TP<=6
>overflow, but at the cost of a division overflow on computers 55 times
>as fast, i.e. P II/200.

>John Stockton's page <http://www.merlyn.demon.co.uk/pascal.htm> contains
>a more detailed discussion of the two problems.
> ...

That topic is now moved to http://www.merlyn.demon.co.uk/pas-time.htm ,
because pascal.htm was getting big.

The pages in the Sig may also be of interest <g>.

--

 Web <URL: http://www.merlyn.demon.co.uk/> --- includes FAQqish topics & links.
 Year 2000 - date2000.htm  Dates - misctime.htm  Critical Dates - critdate.htm
 Don't Mail News.  Y2k for beginners http://www.merlyn.demon.co.uk/year2000.txt



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()

Dr John Stockton schrieb:

Quote:



> > ...
> >That's a different bug which is present in TP/BP 7.0. It cures the TP<=6
> >overflow, but at the cost of a division overflow on computers 55 times
> >as fast, i.e. P II/200.

> >John Stockton's page <http://www.merlyn.demon.co.uk/pascal.htm> contains
> >a more detailed discussion of the two problems.
> > ...

> That topic is now moved to http://www.merlyn.demon.co.uk/pas-time.htm
> because pascal.htm was getting big.
> The pages in the Sig may also be of interest <g>.

> http://www.merlyn.demon.co.uk/year2000.txt

Very, very interesting. It was enough background for me, but I see, it
is not wise to answer without indepth knowledge. On the other hand, I
never had these problems since I always tried to circumvent this power
consuming delay procedure, because I run mostly on DR-Multiuser DOS /
REAL/32. Where every dead time shall be given to another task.

I really suggest the REAL/32 (or similar CCI) for DOS programmers,
except those who make VESA games etc. In the Delphi book I could read
that the multitasking were a benefit of GUI. That's a joke, isnt it?
I have been using Concurrent CP/M-86 since 1983, with TP-3 for CP/M-86.
With any amount of multitasking. And these programs still run without
problems on REAL/32 together with DPMI programs - and Win3.1x.

I know, this was another story...

Regards,
Franz Glaser, http://www.geocities.com/~franzglaser/tp.html
http://members.eunet.at/meg-glaser



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()



Quote:
> Dr John Stockton schrieb:

> > That topic is now moved to http://www.merlyn.demon.co.uk/pas-time.htm
> > because pascal.htm was getting big.

Thanks, John, I'll update my links.

Quote:
> Very, very interesting. It was enough background for me, but I see, it
> is not wise to answer without indepth knowledge. On the other hand, I
> never had these problems since I always tried to circumvent this power
> consuming delay procedure, because I run mostly on DR-Multiuser DOS /
> REAL/32. Where every dead time shall be given to another task.

In this case, I've also got good news for you: my NewDelay patch avoids
this problem and gives up its processor time. At least I've tested it
under Linux and Win3.1, and I was told it works under Win95. Feedback
about other environments, such as the ones you use, is welcome.

Quote:
> I really suggest the REAL/32 (or similar CCI) for DOS programmers,
> except those who make VESA games etc. In the Delphi book I could read
> that the multitasking were a benefit of GUI. That's a joke, isnt it?

Must be. But if one only knows Windoze... :-(
(Not surprising of today's Borland...)-:

--

Internet links:  http://fjf.gnu.de/
Pascal programs: http://fjf.gnu.de/programs.html
PGP keys: http://pgp5.ai.mit.edu/pks/lookup?op=index&search=Frank+Heckenbach



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()



Quote:

> Hi everybody, I'm a very experienced TP-programmer and I have
> an interesting question to ask you all :

>   when programming on a 80286, 80386, 80486 I can use Delay(ms) from
>   the CRT-standard-unit and all works fine.  If I use Delay(5000), then
>   the program waits 5 seconds (= 5000 milliseconds).

>   On the other hand, when programming on a Pentium, P6, AMD K6, etc.
>   something goes wrong with the timing.  It's as if the timer goes
>   three times faster than as usual.  This has the effect that if I
>   use Delay(5000) the program just waits for about 1 second or so.

> Has anybody an idea how this can happen (timer ticks, IRQ, ...) ?
> Please mail me any suggestions (or answers).  I can be found at


> Thanks anyway, Sven Maerivoet, 1990 - 1998
> ==========================================
>  Hi,

         I'm a TP learner and I tried what you said, but the results make
me think that this problem is not general in all Pentium. Delay(5000)
resulted 5 secs. in a Pentium 100 an in a Pentium 200. No prob at all.

        I wish I have helped you.



Wed, 18 Jun 1902 08:00:00 GMT  
 Pentium processors and Delay()


Quote:

>Sorry, but this explanation is not quite right. Since the measuring and
>the Delay use the same loop (not only the same statements, but the very
>same code), the jump prediction will behave the same way in both.

There, however, is one possible problem. As they read different memory
location within the loop (this is so that timer interrupt does not
terminate delay(), like it does with the initialization) they could
cause differences on cache behavior. To my understanding this could
happen only if there is only a direct mapped cache (ie only on 386) and
even the in very rare cases.

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Pentium II Processors

2. Problem with BP and Pentium II Processor

3. Protected mode error using Pentium processor

4. Detecting the Pentium processor

5. Processor independant delay routine wanted

6. Delay and Pentium

7. Delay on Pentium

8. Pentium vs Pentium Pro code

9. Turbo pascal won't work with Pentium 2 processor???

10. about the "delay" procedure on different processors

11. Is it Pascal, or is it my processor?

12. WORD PROCESSOR IN PASCAL

 

 
Powered by phpBB® Forum Software