Как среды выполнения Java, нацеленные на процессоры до SSE2, реализуют базовые операции с плавающей запятой?

Question

Как среда выполнения Java, нацеленная на процессор Intel без SSE2, справляется с денормалями с плавающей запятой, когда strictfp установлен?

Даже когда 387 FPU настроен на 53-битную точность, он сохраняет увеличенный диапазон экспонент, который:

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

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

В любом случае, я не вижу способа избежать хотя бы одной условной ветви для каждого вычисления с плавающей запятой, если только статически нельзя определить, что операция не переполнена / переполнена. То, как рассматриваются исключительные (переполнение / недополнение) случаи, является частью моего вопроса, но это не может быть отделено от вопроса о представлении (стратегия смещения постоянного показателя, по-видимому, означает, что, например, нужно проверять только переполнения).

Answer 1

Это выглядит для меня из очень тривиального теста, например, циклические обходы JVM каждый раз double вычисления через память, чтобы получить округление, которое он хочет. Кажется, что-то странное с парой магических констант. Вот что он сделал для меня для простой программы "compute 2^n naively":

0xb1e444b0: fld1
0xb1e444b2: jmp    0xb1e444dd         ;*iload
                                      ; - fptest::calc@9 (line 6)
0xb1e444b7: nop
0xb1e444b8: fldt   0xb523a2c8         ;   {external_word}
0xb1e444be: fmulp  %st,%st(1)
0xb1e444c0: fmull  0xb1e44490         ;   {section_word}
0xb1e444c6: fldt   0xb523a2bc         ;   {external_word}
0xb1e444cc: fmulp  %st,%st(1)
0xb1e444ce: fstpl  0x10(%esp)
0xb1e444d2: inc    %esi               ; OopMap{off=51}
                                      ;*goto
                                      ; - fptest::calc@22 (line 6)
0xb1e444d3: test   %eax,0xb3f8d100    ;   {poll}
0xb1e444d9: fldl   0x10(%esp)         ;*goto
                                      ; - fptest::calc@22 (line 6)
0xb1e444dd: cmp    %ecx,%esi
0xb1e444df: jl     0xb1e444b8         ;*if_icmpge
                                      ; - fptest::calc@12 (line 6)

я верю 0xb523a2c8 а также 0xb523a2bc являются _fpu_subnormal_bias1 а также _fpu_subnormal_bias2 из исходного кода горячей точки. _fpu_subnormal_bias1 выглядит быть 0x03ff8000000000000000 а также _fpu_subnormal_bias2 выглядит быть 0x7bff8000000000000000, _fpu_subnormal_bias1 имеет эффект масштабирования наименьшего нормального double до наименьшего нормального long double; если FPU округляется до 53 битов, произойдет "правильная вещь".

Я бы предположил, что, казалось бы, бессмысленно test инструкция для того, чтобы поток мог быть прерван путем пометки этой страницы как нечитаемой в случае необходимости GC.

Вот код Java:

import java.io.*;
public strictfp class fptest {
 public static double calc(int k) {
  double a = 2.0;
  double b = 1.0;
  for (int i = 0; i < k; i++) {
   b *= a;
  }
  return b;
 }
 public static double intest() {
  double d = 0;
  for (int i = 0; i < 4100; i++) d += calc(i);
  return d;
 }
 public static void main(String[] args) throws Exception {
  for (int i = 0; i < 100; i++)
   System.out.println(intest());
 }
}

Копая дальше, код для этих операций находится на виду в коде OpenJDK в hotspot/src/cpu/x86/vm/x86_63.ad, Соответствующие фрагменты:

instruct strictfp_mulD_reg(regDPR1 dst, regnotDPR1 src) %{
  predicate( UseSSE<=1 && Compile::current()->has_method() && Compile::current()
->method()->is_strict() );
  match(Set dst (MulD dst src));
  ins_cost(1);   // Select this instruction for all strict FP double multiplies

  format %{ "FLD    StubRoutines::_fpu_subnormal_bias1\n\t"
            "DMULp  $dst,ST\n\t"
            "FLD    $src\n\t"
            "DMULp  $dst,ST\n\t"
            "FLD    StubRoutines::_fpu_subnormal_bias2\n\t"
            "DMULp  $dst,ST\n\t" %}
  opcode(0xDE, 0x1); /* DE C8+i or DE /1*/
  ins_encode( strictfp_bias1(dst),
              Push_Reg_D(src),
              OpcP, RegOpc(dst),
              strictfp_bias2(dst) );
  ins_pipe( fpu_reg_reg );
%}

instruct strictfp_divD_reg(regDPR1 dst, regnotDPR1 src) %{
  predicate (UseSSE<=1);
  match(Set dst (DivD dst src));
  predicate( UseSSE<=1 && Compile::current()->has_method() && Compile::current()
->method()->is_strict() );
  ins_cost(01);

  format %{ "FLD    StubRoutines::_fpu_subnormal_bias1\n\t"
            "DMULp  $dst,ST\n\t"
            "FLD    $src\n\t"
            "FDIVp  $dst,ST\n\t"
            "FLD    StubRoutines::_fpu_subnormal_bias2\n\t"
            "DMULp  $dst,ST\n\t" %}
  opcode(0xDE, 0x7); /* DE F8+i or DE /7*/
  ins_encode( strictfp_bias1(dst),
              Push_Reg_D(src),
              OpcP, RegOpc(dst),
              strictfp_bias2(dst) );
  ins_pipe( fpu_reg_reg );
%}

Я ничего не вижу для сложения и вычитания, но могу поспорить, что они просто делают сложение / вычитание с FPU в 53-битном режиме, а затем возвращают результат в память. Мне немного любопытно, есть ли хитрый случай переполнения, в котором они ошибаются, но я не настолько любопытен, чтобы это выяснить.