On 5/18/2016 12:56 AM, Ethan Watson wrote:
> In any case, the problem Manu was having was with C++.
VU code was all assembly, I don't believe there was a C/C++ compiler for it.
The constant folding part was where, then?
This is why I ask for a compiler option to make it consistent with the C++
floating point architecture I select. Making it better than C++ is great for use
cases where you're not inter-opping with C++ extensively.
Trying to make D behave exactly like various C++ compilers do, with all their
semi-documented behavior and semi-documented switches that affect constant
folding behavior, is a hopeless task.
I doubt various C++ compilers are this compatible, even if they follow the same
ABI.
You're also asking for a mode where the compiler for one machine is supposed to
behave like hand-coded assembler for another machine with a different
instruction set. I doubt any compiler is going to deliver that, unless you
create a customized compiler specifically for that.
Although I do believe saying C++ is just clouding things here. Language doesn't
matter, it's the runtime code using a different floating point instruction
set/precision to compile time code that's the problem. See the SSE vs x87
comparisons posted in this thread for a concrete example. Same C++ code,
different instruction sets and precisions.
Regardless. Making extra build steps with pre-calculated values or whatever is
of course a workable solution, but it also raises the barrier of entry. You
can't just, for example, select a compiler option in your IDE and have it just
work. You have to go out of your way to make it work the way you want it to. And
if there's one thing you can count on, it's end users being lazy.
From your description, there would have been a problem *regardless* of the
precision used for constant folding. This is because the target hardware used
truncation, and constant folding (in all compilers I know of) use rounding, and
no compiler I know of allows controlling the rounding mode in constant folding.
