Why did Turbo Pascal apps fail with a division-by-zero on faster systems?

Re:Why did Turbo Pascal apps fail with a division-by-zero on... by ofibrvev on Saturday August 24, 2019 @02:41PM (#20788901)

Lol because it was a fucking complete ide and compiler on a single low density floppy disk.

And what you’re saying is of course impossible.. determining if the function is called by static analysis is not possible.

If input = 1 then delay end is impossible to analyze statically.

If you meant reference to delay, that is a bit more tractable. But then when do you actually initialize, you will see that program initialization is about the only practical place to do it. Which is exactly what is done.

[ Parent | on HN ]

Re:Why did Turbo Pascal apps fail with a division-by-zero on... by aflag on Saturday August 24, 2019 @03:00PM (#20789020)

Yes, I meant referenced in the code, not necessarily called during execution. It makes sense to do it in the beginning if delay is referenced. I guess it was just a small optimization that they decided to do without then.

[ Parent | on HN ]

Re:Why did Turbo Pascal apps fail with a division-by-zero on... by bonzini on Saturday August 24, 2019 @05:33PM (#20789843)

The loop was in the initialization code of the unit, and the initialization code was monolithic and triggered simply by the "uses crt" statement.

[ Parent | on HN ]

Re:Why did Turbo Pascal apps fail with a division-by-zero on... by ksherlock on Saturday August 24, 2019 @05:32PM (#20789837)

Nowadays with modern linkers, your delay function could have a strong reference to a delay init constructor which would get dragged in, as needed, and run at program start up time.

[ Parent | on HN ]