3 ms·

> 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

> 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.

rasz 7y ago
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.
- Someone 7y ago
  Reading https://retrocomputing.stackexchange.com/a/12112 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 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–1999#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.

rasz 7y ago

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.

Someone 7y ago
Reading https://retrocomputing.stackexchange.com/a/12112 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 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–1999#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.