Строка в Float - контроль четности?

[Мордохвост]

Привет!
Вообщем Delphi пропарсил строку и сделал мне double. И я беру ту же строку и получаю double. Способ мой коротко вот:

@@single:
  movzx     eax,word ptr [r8] //r8 - указатель на WideChar
  sub       eax,$00000030     
  cvtsi2sd  xmm1,eax
  mulsd     xmm0,xmm2         //xmm2 = 10.0
  addsd     xmm0,xmm1
  add       r8,2
  sub       ecx,1
  jz        @@isend

@@pair:
  mov       eax,[r8]             //сразу два
  sub       eax,$00300030
  movzx     edx,ax
  lea       edx,[edx+edx*4]
  add       edx,edx
  shr       eax,16
  add       eax,edx
  cvtsi2sd  xmm1,eax      
  mulsd     xmm0,xmm3         //xmm3 = 100.0
  addsd     xmm0,xmm1
  add       r8,4
  sub       ecx,2
  jg        @@pair
  ... затем коррекция нужной экспы и Power10 и т.д. и т.п.

Затем я сравниваю эти 2 double-а и они не равны! Проваливается на инструкции jp(контроль четности?). И реально: если бинарно смотреть у меня даблы отличаются на один последний бит. На коротких числах jp инструкция пропускает ещё(бинарно равны), но уже на длинных где там 20 цифр или 30 переумножишь/сложишь последний бит не совпадает и jp не пускает Обрабытывал все 100% цифр так же как и дельфин.

Как урегулировать, чтобы мои флоатки были таки эквивалентны делфийским? Есть какой-то регистр msxcr, но он каждый раз меняется после любой операции....

[f.hump]

че-то не понял. ты сделал копипаст кода из какой-то библиотеки (делфи) и копипаст дает результат отличный от оригинала?

[Мордохвост]

Не, это мой код. И результат не совпадает(сравнивая с делфи)

[f.hump]

не совпадает на 1 бит? для длинных чисел так, что у дабла емкости не хватает, чтобы хранить мантиссу во всех подробностях и приходится округлять?

я бы не назвал это отличием.
ну, если хочешь можешь перед счетом добавить что-то типа

    STMXCSR DWORD PTR [rsp-8]
    OR DWORD PTR [rsp-8], 06000h
    LDMXCSR DWORD PTR [rsp-8]

[Мордохвост]

f.hump, повлияло, но вообще катастрофа мой код.

Допустим "-5.722234971514055711914e+200"

Delphi: 0E99DE70F044FBE0C (не знаю сколько он цифр у себя максимально обрабатывает, вроде 18 т.е. все до красных)
Мой: 0E99DE70F044FBE08 (если также макс 18 цифр)
Мой: 0E99DE70F044FBE06 (если макс 36 цифр т.е. красные тоже будет считать)
И это с ldmxcsr or $06000

ок дойду до этого регистра уан дэй

[f.hump]

мои мысли были про то, что возможно метод округления повлиял на результат.

биты 13 и 14 MXCSR определяют метод округления

00 - до ближайшейго
01 - до меньшего
10 - до большего
11 - до меньшего по абсолютному значению

но, с другой стороны метод округления - глобальный параметр, и повлияет на все процедуры использующие SSE.

также разница может быть в том случае если методы Delphi испльзуют FPU, а не SSE

[Мордохвост]

Сообщение от f.hump

но, с другой стороны метод округления - глобальный параметр, и повлияет на все процедуры использующие SSE.

Посмотрел оригинал, сохраняет, но затем переписывает, скопипастил, и кажется только 16 цифр обрабатывать надо.

  sub       rsp,16
  stmxcsr   [rsp]
  mov       dword ptr [rsp],$00001F80
  ldmxcsr   [rsp]

  ....конвертинг

@@done:
  mov       dword ptr [rsp],$00001900
  ldmxcsr   [rsp]
  add       rsp,16

Вооот, вернуло наконец-то мне индентичное. А на x64 там только sse. Клёво, больше не нужно учить этот регистр