i'm trying to debug why the vampire fpu breaks some software that i've written in E and i ran across this anomaly. take this code for instance:

code wrote:

PROC main()   DEF x, y, z, s[16]:STRING   x:=8   y:=6   z:=!x/y -> z:=!(x!)/(y!)   WriteF('\tZ\t= \s\n', RealF(s, z, 8)) ENDPROC

when the vampire fpu is disabled, z returns the correct result -> 1.3333333

when the vampire fpu is enabled, z returns incorrectly -> 1.0000000

also, z returns the correct result with the furia accelerator (with fpu)

however, if you replace line 5 in the above code (z:=!x/y) with the commented line 6 (z:=!(x!)/(y!)) z returns the correct result with both the vampire fpu enabled or disabled.

i'm curious why both versions of the above z equations work with the furia fpu (or fpu in winuae), but only the commented line 6 version of the equation works with the vampire?

Its explained FPU is ment just "to run software not for science"
EXTERNAL LINK 
I am not sure if this bug was previously reported, some were.

It might improve in future (bugfixing) keeping its limits.

Real and full ApolloFPU comes with v4 Vampires

If you want to spend the extra $ for a FPU with more precision then getting the V4 is what you want.
 
Regarding your question.
I do not know E, and do not know what the difference in your instruction is.
  (z:=!(x!)/(y!))
 
  Can you explain it?
 
 
 
 
 

i'll reference this page: EXTERNAL LINK 
from that link: "The first time a ! occurs in an expression the value of the expression so far is converted to floating-point and all the operators and variables after this point are considered floating-point."

the way that i interpret that statement above, this instruction: z:=!x/y implies z:=8.0/6.0

whereas this instruction: z:=!(x!)/(y!) is just a more explicit or verbose way of writing the same thing... convert both x and y to float (8.0, 6.0), then divide them.

if this is a bug in the fpu and it can be fixed, then thats great. if not, i understand... but i guess it would lead me to ask a couple of questions:

in the 2.9 core its not possible to disable the fpu. will it be possible to disable it again in future cores (ie, 3.0)?

if it will not be possible to disable the fpu in future cores, then will earlier cores (2.8) be updated with current registration numbers so that hdmi works in color?

thanx!

can you show the created ASM for this?

but i can provide binaries that can maybe be disassembled.

i've put them here: EXTERNAL LINK 
i've put both versions of the code i posted.

whats included:

xy -> binary of !x/y that doesn't work with the vampire fpu
xy.e -> source
xy.out -> disassembled binary? E has a utility called showhunk that has a disasm option. i'm assuming its a disassembler of some kind

xy2 -> binary of z:=!(x!)/(y!)
xy2.e -> source
xy2.out -> disassembled?

i hope that helps!

Hence, your X/Y (integer divide assumed) results as 1 then is cast to a float with the ! at the beginning.  It's an order of operations effect.

I doubt this is FPU related. Operator precedence is typically governed by integer operation. To confirm I tried to look at the disasm code provided in the link. Unfortunately the disassembler didn't know of FPU opcodes, resulting in unreadable disassembly. :-(

To know which from interpretation 1) or 2) is good, the knowled of an E expert about operator precedence might be valuable. May be it is the Furia result which is wrong.

I doubt that the Furia is wrong, if using the 68882 then it is canonically correct for existing software.

In C an equivalent group of forced precedence tests might be something like:

int x=8, y=6;
float result_idivi = (float)(x / y);
float result_fdivi = (float)(((float)x) / y);
float result_idivf = (float)(x / ((float)y));
float result_fdivf = (float)(((float)x) / ((float)y));

That way you can test the differences across a range of ordering operations.