...
I would like to know what is going on at all? This is a banal addition of numbers, but the compiler does not translate 30 + 33 into 63. He does double addition.
...
...Then maybe it is worth trying also:
Just curious if something changes if the code changes a bit?
useEl^.rh2 := ry1 + single(30 + 33);
Then maybe it is worth trying also:Это сработало! Компилятор не разбирает, что в выражении присутствуют числа и не анализирует код вообще? Работает компилятор с SIMD и тут такой код:
useEl^.rh2 := 30 + 33 + ry1; useEl^.rh2 := ry1 + (30 + 33);
useEl^.rh2 := ry1 + 30 + 33; // := ((ry1 + 30) + 33)
they'll be not.*snip*I'm just explaining why, I had not assessed it as neither right or wrong.
In principle, this can not be considered that way. And this is not the right behavior!
Correct behavior: if the result is type Single, and the expression is type Integer and type Single, then we convert all values to type Single (by the value of the result) and recalculate.
Another correct behavior is when all dimensions of the same type are in the expression (let's say Integer). Then we calculate the value and translate it into a Single type value.
We should not mix types in expressions - this leads to overhead. Therefore, all values should be immediately converted to the same type.
In principle, this can not be considered that way. And this is not the right behavior!
Correct behavior: if the result is type Single, and the expression is type Integer and type Single, then we convert all values to type Single (by the value of the result) and recalculate.
.section .rodata.n__$TTEST$_Ld1,"a"
.balign 4
.globl _$TTEST$_Ld1
_$TTEST$_Ld1:
# value: 0d+3.000000000E+01
.byte 0,0,240,65
.section .rodata.n__$TTEST$_Ld2,"a"
.balign 4
.globl _$TTEST$_Ld2
_$TTEST$_Ld2:
# value: 0d+3.300000000E+01
.byte 0,0,4,66
Pascal does not consider the result type when determining the result type of an expression. Also as y.ivanov wrote, expressions are evaluated left-to-right and its completely legitimate for the compiler not to optimize this.Лично моё мнение - это не правильно. Но возможно ни кто и не занимался данным вопросом. Если это интересно для развития FPC, то я могу заняться созданием анализатора кода и оптимизацией кода паскаля (не ассемблерного, а именно паскаля). Протестируете, посмотрите как работает и есть ли от него смысл.
*snip*
Besides, It's bad thing to rearrange FP arithmetic, will yield a different result.
*snip*Have you tried my snippet from reply #11? It is actually an example from the link.
y.ivanov, это знать желательно при разработке, но я вёду речь не об этом. :)
Yandex translate:
y.ivanov, it is desirable to know this when developing, but that's not what I'm talking about. :)
By my understanding, what you're talking about is to pre-calculate at compile time with what is known by the compiler.
By my understanding, what you're talking about is to pre-calculate at compile time with what is known by the compiler.Yes.
+1
Besides, It's bad thing to rearrange FP arithmetic, will yield a different result.
I have added an optimization for this but it is only active in "fastmath" mode: https://gitlab.com/freepascal.org/fpc/source/-/commit/5a617cd1082e80008559a012673db2eecb6304bf (in fastmath mode the compiler does transformations which are mathematically valid but might break due to floating point number behaviour)."fastmath" не обязателен. Достаточно произвести проверку что сумма/разность чисел идущих друг за другом не теряют своего конечного значения (первое значение не поглощает значение второго числа).