OK : but to my mind, simulator is a debuging tool ; so it is not supposed to stop working in case of code mistake.Your intermediate sum (52488 * 41472) is so large that even the computer software can't currently calculate it without overflow, keep all results under 65535 to match PICAXE.
Crossing posts...We can correct the simulator software to allow a longer type and then give a value equivalent to the real chip result, however the results will not be meaningful in either a real chip or simulator when you start to overflow.
The problem is not only that the result is not correct...The differences are due to the way computers 'do sums' rather than the PICAXE. We'll have another look at the PE6 large multiplications to ensure the simulation matches the real chip.
This was something I requested in the PE6 wishlist, a flag in the simulator that indicated that a PICAXE overflow had occured.We can correct the simulator software to allow a longer type and then give a value equivalent to the real chip result, however the results will not be meaningful in either a real chip or simulator when you start to overflow.
BUT : there is not any overflow in my code. There is only a bug in PE6 (witch is a beta version) and PE6 crashes.This was something I requested in the PE6 wishlist, a flag in the simulator that indicated that a PICAXE overflow had occured.
Technical,Your intermediate sum (52488 * 41472) is so large
The result of the ** calculation could be used to detect overflow.Multiplication and Division
When multiplying two 16 bit word numbers the result is a 32 bit (double word)
number. The multiplication (*) command returns the low word of a word*word
calculation. The ** command returns the high word of the calculation and */
returns the middle word
Therefore in normal maths $aabb x $ccdd = $eeffgghh
In PICAXE maths
$aabb * $ccdd = $gghh
$aabb ** $ccdd = $eeff
The X1 and X2 parts also support return of the middle word
$aabb */ $ccdd = $ffgg
Indeed. However to get the high word using **The original post calculates 52488 ** 41472, not 52488 * 41472
I do not agree !However to get the high word using ** you still need to do the * to start with !
There is not really an overflow !The result of the ** calculation could be used to detect overflow.
But there where one in PE6 simulation program...This maths was previously overflowing the double type used in the simulation software calculation, we have now changed the simulation software to use a long instead to resolve this. Therefore this will be fixed in the next release.
Technical,However to get the high word using ** you still need to do the * to start with!
#picaxe 40X2
w0=52488
w1=41472
serout C.1,N2400,("w0=",#w0,9,"w1=",#w1,9,"w2=",#w2,13,10)
stop
#picaxe 40X2
w0=52488
w1=41472
w2=w0*w1
stop
How is the simulator meant to know what the high word of the result is, without calculating the whole sum to start with? We were not meaning to do the * maths in your PICAXE program in order to get the ** result, we were meaning that the simulator itself always has to do the * (internally) so that it actually knows what the high word (**) part of that result actually is! Sorry if this confused you.I'm not sure this is the case.
So I have to use a workaround...It will be available in the next release, but we do not have a release date for that yet.
#picaxe 40X2
#no_table
#simspeed 1
w0=52488
w1=41472
'w2=w0*w1
'w3=w0**w1
gosub Multi
sertxd("w2=",#w2," w3=",#w3,13,10)
end
Multi:
if w0<$8000 or w1<$8000 then
w2=w0*w1
w3=w0**w1
else
w0=w0 and $7FFF
w1=w1 and $7FFF
w2=w0*w1
w3=w0**w1
w3=w0+w1>>1+w3+$4000
endif
return
Any news ?It will be available in the next release, but we do not have a release date for that yet.