delphi – 为什么应用程序以不同于Default8087CW的FPU控制字开始？

可以帮助我了解在Win32平台上的Delphi应用程序中使用FPU Control Word的功能.

当我们创建一个新的VCL应用程序时,控制字设置为1372h.这是我不明白的第一件事,为什么是1372h而不是1332h这是System80中定义的Default8087CW.

这两者之间的区别：

1001101110010  //1372h
1001100110010  //1332h

是根据文档保留或不使用的第6位.

第二个问题关于CreateOleObject.

function CreateOleObject(const ClassName: string): Idispatch;
var
  ClassID: TCLSID;
begin
  try
    ClassID := ProgIDToClassID(ClassName);
{$IFDEF cpuX86}
    try
      Set8087CW( Default8087CW or $08);
{$ENDIF cpuX86}
      OleCheck(CoCreateInstance(ClassID,nil,CLSCTX_INPROC_SERVER or
        CLSCTX_LOCAL_SERVER,Idispatch,Result));
{$IFDEF cpuX86}
    finally
      Reset8087CW;
    end;
{$ENDIF cpuX86}
  except
    on E: EOleSysError do
      raise EOleSysError.Create(Format('%s,ProgID: "%s"',[E.Message,ClassName]),E.ErrorCode,0) { Do not localize }
  end;    
end;

上述功能是将控制字改为137Ah,所以打开第3位(溢出掩码).我不明白为什么调用Reset8087CW之后,而不是恢复进入功能之前的单词的状态？

解决方法

第6位被保留并忽略.这两个控制词实际上在FPU行为相同的意义上是相等的.系统刚刚设置保留位.即使您尝试将值设置为$1332,系统将其设置为$1372.无论你问第六位有什么价值,它都将被设置.所以,当比较这些值时,你不得不忽略这一点.这里没什么可担心的

对于CreateOleObject,作者决定,如果要使用该函数,那么在使用COM对象时也会掩盖溢出,甚至超出.谁知道为什么他们这样做,只有32位代码？他们可能发现一堆常规溢出的COM对象,所以添加了这个粘贴石膏.在创建时屏蔽溢出还不够,在使用对象时也需要完成,所以RTL设计人员从此以后选择忽略溢出.

或者也许是一个bug.他们决定不修复32位代码,因为人们依赖于这种行为,但是他们修复了64位代码.

无论如何,这个功能什么也没有.你不需要使用它.你可以写你自己的,做你想做的事情.

使用互操作时,浮点控制是一个问题. Delphi代码期待未屏蔽的异常.用其他工具构建的代码通常会掩盖它们.理想情况下,当您调用Delphi代码并在退货时将其解除掩码,您将屏蔽异常.期望其他库可以随意更改控制字.还要注意,Set8087CW不是线程安全的,这是Embarcadero多年来拒绝解决的一个巨大问题.

前进没有简单的方法.如果您不在程序中使用浮点数,那么您可以简单地掩盖异常,可能会很好.否则,您需要确保在所有线程的所有点上适当地设置控制字.一般来说,使用标准的Delphi RTL是不可能的.我个人使用线程安全版本替换RTL的关键部件来处理这个问题.我在这份QC报告中记录了如何做到这一点：QC#107411.

delphi – 为什么应用程序以不同于Default8087CW的FPU控制字开始？

解决方法

相关推荐