"Pentium-safe FDIV" ... in 2014?

Every time I look in the compiler settings, the same question comes to my mind: why in the current Delphi compiler is there a compiler option "Pentium-safe FDIV"?

Pentium-FDIV-Bug was discovered in November 1994 and did not appear on 1995 processor models. The processors at that time were probably quite robust with Windows 95, 98, and possibly Me too. As far as I know, the first Intel Pentium 1 processor with a frequency of 133 MHz (and, therefore, fast enough to achieve the minimum system requirements of Windows 2000) was released in June 1995 without FDIV errors, of course.

VCL / RTL of current Delphi versions uses the Windows APIs, which are not available on older operating systems. Windows 98 and Me do not work with the empty Delphi XE6 VCL application; I have not verified that the VCL / RTL Delphi XE6 has already broken compatibility with Windows 2000, but I think so.

So, why does Embarcadero support the compiler that was used in 1994, when they refuse to support the operating systems that were used in 2000? Ergo, no one will require this compilation option, since the affected processors will not be compatible with the operating systems that VCL / RTL requires in any case.

Refresh To clarify the question: is there a precedent when this switch can be useful? Or maybe the compiler internally ignores this parameter, and it just has to save the parameters for the old project files?

+6
source share
4 answers

Pentium division error affected a number of early Pentium models. The highest clock frequency of the affected models was 100 MHz. White papers show that Delphi XE6 targets Vista and higher, but in fact you can still target Windows XP, and I believe that XE6 can create executable files that run on Windows 2000. The minimum requirements for XP are 233 MHz processor, and for Windows 2000 - a processor with a clock speed of 133 MHz.

So, it's almost believable that you can run code compiled by XE6 on a failed Pentium processor. In fact, no one at Embarcadero, at least in the last 15 years, will feel any obligation to support defective Pentium processors. They simply were not seen in the wild in the 21st century.

So why the compiler function has not been removed? Only Embarcadero knows the answer to this, but I can give you a few obvious reasons:

  • Removing a function violates backward compatibility. If there are people who, even if they don’t need it, build with the switch on, then removing it will affect them.
  • Removing the value of a function. This includes changes to the user interface, compiler, documentation, test suite, etc.
  • Deleting a function leads to risk. Every time you change a code, a code that has been checked and tested over the years, you risk introducing a new defect.
+7
source

If you are looking for an “official” answer, you are unlikely to receive it. Unofficially, I certainly can point to David's answer. His three questions of reasoning are clear. If there is no compelling reason to remove this feature, it does not make much commercial or technical sense. The only reason it should be deleted is that the x86 source code was completely rewritten from scratch ... in this case, it is not deleted so much, but simply will not be taken into account in the first place.

I note that the new ARM backups based on AMD64 / ia64 and LLVM do nothing with this directive, since it is axiomatic that these CPUs are not executed. The directive / option is recognized, but simply ignored.

+5
source

Delphi still prefers to create console applications. And if your console application does not use the new window API, you can easily make it compatible with Windows 95.

0
source

These are just rumors, but the Delphi compiler seems to be written in an assembly and is largely uncontrollable. They do not remove any functions simply because it is incredibly difficult to make any changes to the compiler so that they are not worried.

0
source

Source: https://habr.com/ru/post/970513/


All Articles