Hacker News Reader

Comment by Wowfunhappy | Hacker News Reader

> Turbo Pascal programs start by calibrating a delay loop (so that the Delay function knows how much to spin to achieve a certain delay). The calibration counts the number of times a certain loop is run for 55ms (as measurable using the PC’s timer interrupt with its default setting), then divides the number of loops by 55 so that Delay can then busy-wait in millisecond increments.

Why not use the PC's timer interrupt for the delay function itself?

View on HN

MS-DOS kinda expects the timer interrupt to only fire at around 18.2hz I think so it's too coarse for millisecond delays.

I always assumed it was 16hz. Oh well. That was a long time ago.

You can read the timer's countdown counter instead of relying solely on the tick; it runs at 1.2 MHz approximately.

ms dos compatible != IBM PC compatible. 80186 based PC will still run TP programs, despite Timer0 being mapped to port 30-36H instead of 40-43H, not to mention totally non 8253 compatible.

Because your delay resolution is then 55 ms, and accuracy is plus or minus 55 ms, and using interrupts is really complicated.

The slow timer actually works in your favor if you do it right. You don't count interrupts, you count CPU cycles between interrupts (search term: "reciprocal counter.")

This bug was just laziness on Borland's part; there were no excuses for it. There were any number of ways to do it correctly. Fortunately they fixed it pretty quickly, too. While I remember running into it, it wasn't a huge issue.

No excuse? It may have been a left-over from early versions.

The original Turbo Pascal ran on PCs of the day, running at 4.77MHz, and with 64 kilobytes of RAM.

Even if one foresaw computers running at 200MHz, I don’t think that, at the time, it was clear that a single architecture would stay around long enough for that to be a problem. The Pentium Pro peaked at 200MHz in 1995-8 or so, 12 to 15 years after the first release of Turbo Pascal (https://en.wikipedia.org/wiki/Pentium_Pro)

> It may have been a left-over from early versions.

Earlier versions do not have this particular bug, it was introduced in version 7. However they have another bug which causes Delay to simply not work properly (it finishes quicker than requested) and most likely the changes in ver7 were made in an attempt to fix that one.

I think its the very same bug, they just bumped counter from 16 to 32 bit, but left the rest of logic intact, including 16 bits for the result of division.

Reading https://retrocomputing.stackexchange.com/a/12112, they moved the limit from ≈20MHz (num iterations overflowed 16 bits, leading to incorrect computation of the number of loops to run per second) to ≈200Mhz (num iterations divided by 55 overflowed 16 bits, leading to this “divide by zero” message)

(Aside: all things staying the same, that should have increased the limit by a factor of 55. It seems the processor got more efficient running these idle loops by a factor of about five (about 2½ if there’s a sign bit in the result of the division)

So yes, you could call this a different bug. I don’t think having that bug in the code is inexcusable, though.

TP7 is from March 1993 (http://progopedia.com/version/turbo-pascal-7.0), and it seems the first 200Mhz PC CPU was from November 1995 (https://en.wikipedia.org/wiki/Timeline_of_computing_1990–199...)

⇒ I don’t think they could have found this in testing. So, is it inexcusable that this went through code review? I don’t think so. Not only would one have to realize that that new limit now came into play, one also would have realized the higher efficiency of the 200MHz processor(s) would bring the number down further.

Turbo Pascal is old enough that (I think) they probably wanted to keep compatibility with machines that ran MS-DOS but weren't IBM PC-compatible. If that's the case, messing with the timer interrupt would've been a bad idea.

Nah, this is TP7 and it already was exclusively for PCs. I think 3.0 was the last version that was ported to other systems.

Reply on news.ycombinator.com