PE 6.0.8.0 simulation : problem with **

BESQUEUT

Senior Member
Can-you confirm problem with simulation and step by step of this little code ?
Code:
#picaxe 40X2
#no_table
#simspeed 1

w0=52488
w1=41472
w2=w0**w1
sertxd("w2=",#w2,13,10)
or I have another specific problem...
 

Technical

Technical Support
Staff member
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.
 

BESQUEUT

Senior Member
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.
OK : but to my mind, simulator is a debuging tool ; so it is not supposed to stop working in case of code mistake.
I will check what happed with real Picaxe, but I guess it will be OK.
Simulator is supposed to do same as real Picaxe.

What is "computer software" ?
Tryed with Excel : answer is 2 176 782 336 =33215 * 65536 + 4096

** is supposed to be a 32 bits multiplication, IE till 4 294 967 296
 
Last edited:

Technical

Technical Support
Staff member
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.
 

BESQUEUT

Senior Member
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.
Crossing posts...
I don't understand where is the overflow ?

If you are using short signed integers, this is not appropriate as Picaxes are using unsigned 32 bits integers...
 

AllyCat

Senior Member
Hi,

Yes, I've noticed in the past (with PE5) that although the PE supports some 32-bit internal calculations, the actual values used are (sometimes?) 31 bits + sign.

Added: See my first code sample in #1 of this thread.

Cheers, Alan.
 
Last edited:

Technical

Technical Support
Staff member
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.
 

BESQUEUT

Senior Member
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.
The problem is not only that the result is not correct...
The problem is that I have to restart PE6 each time my code encounter a big multiply... that is a big punishment...

the way computers 'do sums' What do you mean ????
A sum is a sum. If using correct variable type, the result should be exact, and consequently, the same using any computer or a Picaxe.

And multiplying two 16 bits unsigned integers is meaningfull and have a 32 bits unsigned integer result.
 
Last edited:

Buzby

Senior Member
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.
This was something I requested in the PE6 wishlist, a flag in the simulator that indicated that a PICAXE overflow had occured.
 

BESQUEUT

Senior Member
This was something I requested in the PE6 wishlist, a flag in the simulator that indicated that a PICAXE overflow had occured.
BUT : there is not any overflow in my code. There is only a bug in PE6 (witch is a beta version) and PE6 crashes.

(and things like "results will not be meaningful " or "the way computers 'do sums'" are more "charabia" than acceptables explanations.)
 

Flenser

Senior Member
Your intermediate sum (52488 * 41472) is so large
Technical,

The original post calculates 52488 ** 41472, not 52488 * 41472.

From page 24 of the basic manual the picaxe firmware supports this:

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
The result of the ** calculation could be used to detect overflow.
 

Technical

Technical Support
Staff member
The original post calculates 52488 ** 41472, not 52488 * 41472
Indeed. However to get the high word using ** you the simulator still need to do the * to start with!
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.
 
Last edited:

BESQUEUT

Senior Member
However to get the high word using ** you still need to do the * to start with !
I do not agree !
Is this a limitation of PE6 simulator ?
I am working on an implementation of floating numbers on Picaxes.
I only need the 16 more significative bits of any calculation.
So, for me, no need for the * operator in this case.

The result of the ** calculation could be used to detect overflow.
There is not really an overflow !
(Or there is an overflow each time ** result is a number greater than zero...)
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.
But there where one in PE6 simulation program...

Now, I am stuck. When will this new version be released ?
 
Last edited:

Flenser

Senior Member
However to get the high word using ** you still need to do the * to start with!
Technical,

I'm not sure this is the case. The manual doesn't give this requirement and when I test it in PE v5.0.0 I can run the ** or */ calculation without having done any prior * calculation.

The other thing is that we all appear to have misunderstood what BESQUEUT was actually referring to in his original post when he said there was a "problem with simulation" doing the w2=w0**w1 calculation.

When I test it now in PE v6.0.7.5
This code runs in the simulator in ~1 sec
Code:
#picaxe 40X2

w0=52488
w1=41472
serout C.1,N2400,("w0=",#w0,9,"w1=",#w1,9,"w2=",#w2,13,10)
stop
But, when I run the following code the simulation does not end, you cannot stop the simulation, you cannot exit PE while a simulation is in progress and I end up having to kill PE using the Windows task manager.
Code:
#picaxe 40X2

w0=52488
w1=41472
w2=w0*w1
stop
I've deliberately done my test using "w2=w0*w1" in place of the original "w2=w0**w1" to show that the simulation problem BESQUEUT found is not related to using the ** operator.
 

Technical

Technical Support
Staff member
I'm not sure this is the case.
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.

We can end this discussion here, the simulator issue is now fixed so that *, ** etc. work as in a real chip for these very high values.
It will be available in the next release, but we do not have a release date for that yet.
 

BESQUEUT

Senior Member
It will be available in the next release, but we do not have a release date for that yet.
So I have to use a workaround...
Code:
#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
In case someone is also stuck with that ...
 
Top