Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 08:11am 18 Jul 2014
Copy link to clipboard
Print this post
@JohnS
The code I posted above benchmarks 5 decimal digits per MMBasic var against 3 decimal digits per MMBasic var.
I can't goto 6 digits per MMBasic Var because that would lose precision,
ie 999,999 + 999,999 = 1999998 which in MMBasic would be 2.00000e+06 (try Print 999999+999999 in MMBasic) since MMBasic is limited to 6 digit precision.
PeterThe only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 08:26am 18 Jul 2014
Copy link to clipboard
Print this post
PRINT may do that but according to the manual it's held correctly.
Sounds like PRINT is a bit buggy / misleading.
Isn't there a formatting thing (STR$?) or some such to confirm it?
Anyway, what happens if you use more digits? Should work, since 16777100 is where it actually changes (i.e. 16777100+1 won't be exactly 16777101, assuming the manual is right as I expect it to be).
JohnEdited by JohnS 2014-07-19
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 08:33am 18 Jul 2014
Copy link to clipboard
Print this post
@Boss
I'm dead against putting in special support for specific hardware into a language. I know MMBasic has some special support, but IMHO it shouldn't. What MMBasic should have is some way of pulling in libraries of compiled code to support specialist devices, but that is really difficult to implement I believe. DDS's are a bit of a specialist device, IMHO of great interest to us folks who do RF things, but generally not to anyone else !! I understand that what U have proposed is not support of any specific chip or h/w device because all DDS's operate off the same fundamental equation, but nonetheless it still feels to me like a very specialist niche function useful to only a very small subset of uMite users.
Of much more use and wide applicability is to add functions which can be used for multiple purposes not just a very narrow application purpose, eg DDS, hence why having Add32, Sub32, Add64, Sub64 and if possible Mul32,Mul64,Div32 and Div64 together with of course supporting functions to make moving data into and out of 32/64 bit land easy, Bin32ToAsc$, Bin64ToAsc$, Asc32ToBin, and Asc64ToBin would be really great additions to MMBasic
The other thing is that in order to calculate DDS tuning words precisely, one really has to use Double Precision arithmetic and in particular Double Precision multiplication. The minute you do that, the C compiler will have to pull in it's Double Precision arithmetic library and the generated code size balloons. I'm pretty sure that the PIC32MX1/2's (at US$5 that would be the bargain of the century) do NOT have h/w FPUs so it will be software, I could of course be wrong, and with the availability of 32 bit Mul in MIPS assembler the Double precision multiplication code might in fact be quite small.
But as I said before, I'm against adding specific device support to a programming language.
Interesting debate !
PeterThe only Konstant is Change
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 08:51am 18 Jul 2014
Copy link to clipboard
Print this post
@JohnS
This is where it all started for me !! The uMite manual states on page 33
which gives the impression that there is 9 digit precision which clearly it can't be with just 4 bytes per float, but I lived in hope for a very short time !
The manual also as you say, states on page 33
which gives the impression that MMBasic numeric vars have 8 digit precision which clearly they don't
I initially thought, the DDS calcs are going to be a walk in the park what with all this precision floating about, but of course MMBasic's precision is actually 6 digits.
Try this
A=999999
B=999999
C=A+B
Print C
Print C/10
What U will get is
> RUN
2.00000e+06
200000
>
The answer should of course be 1999998 and 199999.8 respectively
Which demonstrates that there is NO internal precision greater than what one sees.
Now try this test
'16777100 Test
'Set A to be 3 less than maximum positive integer according to Page 33
A=16777097
'We're going to add 1
B=1
'So if Page 33 is correct then C should be 16777098
'ie 16777097+1
C=A+b
Print C
'Divide by 10 just in case theer is an extra digit lurking somewhere
Print C/10
When run you get
RUN
1.67771e+07
1.67771e+06
>
We should of course have got 16777098, and 1677709.8 respectively if Page 33 was 100% accurate.
STR$ can indeed format a number but it can't add precision
So that's why I had to spend 3 weeks writing my extended precision BCD library, and then as each week goes by optimising it further to make it go faster. I think what I'm going to do is use 5 decimal digits per MMBasic Var for Add/Subtract, and then have functions to convert from 5 digit to 3 digits and back again for Multiply and Divide - Mul & Div are used far less often, and if I plan the AD9850 controller s/w well enough I may be able to get away from needing Multiply at all.
73
PeterEdited by G8JCF 2014-07-19The only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 09:08am 18 Jul 2014
Copy link to clipboard
Print this post
16777100 is 7 (and a fraction) digits, in effect, not 8.
PRINT is almost certainly just using a display format that is confusing.
The point is that at some value
x = y + 1
x = x - y
will not be 1.
The manual says the smallest integer y is 16777100 when that happens.
For convenience you'd like to do
x = (as many 9s as possible) + (the same 9s)
and have x be exact.
Now, 9999999+9999999 is >16777100 so that's too many 9s.
But 999999+999999 should be fine even if PRINT makes it look otherwise.
When working out if a carry occurred you should be safe comparing against 1000000
(PRINT's behaviour may mean you'll need a workaround for PRINT such as printing the first digit then printing (x - that digit * 1000000).)
JohnEdited by JohnS 2014-07-19
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 09:35am 18 Jul 2014
Copy link to clipboard
Print this post
@JohnS
So that means that if I do C=(999999+999999)/1000 should I get full precision in C, ie 1999.998 because there are hidden extra precision digits ?
I'm clearly not fully understanding what you're saying, all I know is that adding 999999 to 999999 gives the answer 2.00000e+06, and if there is/are some extra precision digit(s) then dividing by 1,000 should show them I would have thought. Whereas adding 99999+99999 gives the correct answer of 199998 ie no loss of precision.
Are you going to report that you suspect that there is a bug/strange behaviour with the PRINT statement to Geoff ?
I'd dearly love there to be extra precision somewhere in MMBasic, but thus far I can't find it despite writing thousands of lines of MMBasic :( If anybody can post a code sample or two which demonstrates how to access the extra precision that would really help me, and I would be very grateful indeed. Perhaps I'm just too close to the coalface to spot the trick ?
73
PeterThe only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 09:45am 18 Jul 2014
Copy link to clipboard
Print this post
The division by a power of 10 is a problem.
The 999999+999999 is OK, but when you start dividing (especially by 10s) you get another floating point issue. You could probably divide OK by powers of 2.
I'll try to explain.
The 32 bits we have are roughly:
1 for the sign
some for the exponent (which is a power of 2 or 8 or 16 or whatever but not 10)
the rest for the digits (known as mantissa)
If you start with x=0 (zero) and repeatedly add 1, what happens is there is some exponent (think of it as 1) and the mantissa stores the integer that's counting up.
Then at some value it won't fit. So, the exponent gets bigger and the mantissa is made to fit, by chopping off as many low order bits as necessary (one, often).
Apparently the mantissa when this happens is after 16777100.
Right, back to dividing by some power of 2 or 10.
To divide by a power of 2 you can just adjust the exponent.
It's a bit awkward dividing by a power of 10 because the exponent means powers of 2. Conceptually you work out the mantissa multiplied by the power of 2, then divide by the power of 10 and finally reconvert back to an exponent of powers of 2 and whatever mantissa is needed. Generally some bits have to be chopped so the mantissa is inexact but fairly close to the right number.
However, I'd understood you did not need to do division with (or of) these extra-precise numbers!
I'm going to post some more next...
JohnEdited by JohnS 2014-07-19
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 09:53am 18 Jul 2014
Copy link to clipboard
Print this post
I'd love some MMBasic code please if that's possible to demonstrate/clarify the point
Thanks
PeterThe only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 09:57am 18 Jul 2014
Copy link to clipboard
Print this post
Carrying on...
When you add 999999+999999 you almost for sure do get the correct value. How to see it?
PRINT sounds to be "friendly" with big numbers and is apparently printing a particular way. It does look a bit like a bug - but not if the "friendly" way is what is intended. Then it wouldn't be a bug it would be a feature. A misleading feature, sadly.
Only Geoff will know if it's intentional.
You can work around it with something along the lines of:
x = 999999 + 999999
if x < 1000000 'well we know it isn't but bear with me
then print x
else print x \ 1000000; : print x - x \ 1000000 * 1000000
Sorry for the rubbish Basic, I'm happier with C.
Instead of that mess you'd use STR$ or is there a FORMAT$ or whatever... and then PRINT it.
John
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 10:09am 18 Jul 2014
Copy link to clipboard
Print this post
@JohnS
THANK YOU !!!!!
x = 999999 + 999999
if x < 1000000 then
print x
else
print x \ 1000000;
print x - (x \ 1000000) * 1000000
Endif
Result
> RUN
1 999998
>
which is correct
OK, I'll up the number of digits processed from quintets to sextets and give it a whirl.
Once again, very many thanks, your Basic code snippet made it all clear to me!!
Take care, have a great evening, and thank you
Peter
The only Konstant is Change
boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268
Posted: 10:53am 18 Jul 2014
Copy link to clipboard
Print this post
Hi Peter,
I understand what you mean but I think you are only "partially" right. I personally don't consider LCD, Encoder, PWM, and other HW dependent commands as regular " Basic commands" but as "a kind of binary library" instead. Otherwise DDS is almost standard in sinusoidal signal generation. It covers frequencies from uHz to GHz. Just consider how much slower will be LCD library written in Basic than "compiled version". And with DDS chip programming every uS counts (ie. if you want to use DDS as sweep generator).
And the most desired command (for me) should be "COMPILE".
Regards
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 11:07am 18 Jul 2014
Copy link to clipboard
Print this post
Quick note that 16777100 is slightly odd.
If the mantissa is (24 or maybe 23) bits you'd expect the number to be 16777215 (being 24 bits all set to 1).
(There's often a "hidden" bit, don't ask - but by all means google.)
So why 16777100... don't know, may even not be so but it's near enough I suppose!
John
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 11:57am 18 Jul 2014
Copy link to clipboard
Print this post
Hi
Thanks to @JohnS's insight (and perseverance with me !), I have coded up for benchmarking purposes BCD Add and Subtract test suites using 6 decimal digits per MMBasic Numeric Var, along with 5 Digits and 3 digits for comparison purposes.
Each function is executed 100 times and the result is the duration of 100 executions/100 to give a per iteration time in mS. Interestingly I found that specifying numbers in hex format leads to slightly quicker runtimes than if I use long handed numbers or scientific notation, eg &HF4240 is quicker than 1E6 which is quicker than 1000000.
To give you some idea of performance, 343,597383,680000 + 34,359738 takes about 1.63 mS with CPU 48, and 343,597383,680000 - 34,359738 takes about 1.67 mS with CPU 48.
6 digits per MMBasic numeric Var is much more coder friendly than 5 digits, the conversion to and from 3 digits per MMBasic var (required so ,that I can do Mul and Div) is much more straightforward, and in the case of the AD9850Controller.bas the calculation of the real Tuning Word sent to the DDS chip involves dividing by 1,000,000 which just means losing the last MMBasic numeric var, whereas with 5 digits, that would have been somewhat more involved.
I think that for all practical purposes we must be getting close to the performance levels required for hand turned rotary encoders when tuning DDS's - quicker is always better of course.
Anyway, here's the code, and as before any suggestions for further improvement would be very much appreciated.
Once again, thank you @JohnS
73
Peter
CPU 48
'Up to 42 Digit BCD, 6 Decimal Digits per Single
DIM BCDA(6),BCDB(6)
'Test using DDS AD9850 Numbers
'Tuning Word for 10,000,000Hz is 343597383.68
'Increment for 1Hz 34.359738368
'Now scale everything by 1E6 so that we can do everything
'using integer arithmetic
'Tuning Word for 10,000,000 = 343,597383,680000
'Increment for 1Hz 34,359738.368
Iterations=100
PRINT "Testing with 6 digits per single"
'Load the BCD Registers
ClrBCD BCDA(0)
BCDA(0)=680000
BCDA(1)=597383
BCDA(2)=000343
ClrBCD BCDB(0)
BCDB(0)=359738
BCDB(1)=000034
'Subtraction Test
TIMER=L
FOR I=1 TO Iterations
BCDA(0)=BCDA(0)+&HF4240-BCDB(0)
Cy=1-(BCDA(0)\&HF4240)
BCDA(0)=BCDA(0) MOD &HF4240 '&HF4240=1E6
BCDA(1)=BCDA(1)+&HF4240-BCDB(1)-Cy
Cy=1-(BCDA(1)\&HF4240)
BCDA(1)=BCDA(1) MOD &HF4240
BCDA(2)=BCDA(2)+&HF4240-BCDB(2)-Cy
Cy=1-(BCDA(2)\&HF4240)
BCDA(2)=BCDA(2) MOD &HF4240
' BCDA(3)=BCDA(3)+&HF4240-BCDB(3)-Cy
' Cy=1-(BCDA(3)\&HF4240)
' BCDA(3)=BCDA(3) MOD &HF4240
NEXT I
TIMER=L
FOR I=1 TO Iterations
BCDA(0)=BCDA(0)+BCDB(0)
Cy=BCDA(0)\&HF4240
BCDA(0)=BCDA(0) MOD &HF4240 'HF4240=1E6
BCDA(1)=BCDA(1)+BCDB(1)+Cy
Cy=BCDA(1)\&HF4240
BCDA(1)=BCDA(1) MOD &HF4240
BCDA(2)=BCDA(2)+BCDB(2)+Cy
Cy=BCDA(2)\&HF4240
BCDA(2)=BCDA(2) MOD &HF4240
' BCDA(3)=BCDA(3)+BCDB(3)+Cy
' Cy=BCDA(3)\&HF4240
' BCDA(3)=BCDA(3) MOD &HF4240
BCDA(3)=Cy
NEXT I
PRINT (TIMER-L)/Iterations;" 6-Decimal Digits:Addition: ";
PrintBCDA(6)
PRINT "Now testing with 5 digits per single"
'Load the BCD Registers
ClrBCD BCDA(0)
BCDA(0)=80000
BCDA(1)=73836
BCDA(2)=34359
ClrBCD BCDB(0)
BCDB(0)=59738
BCDB(1)=00343
'Subtraction Test
TIMER=L
FOR I=1 TO Iterations
BCDA(0)=BCDA(0)+&H186A0-BCDB(0)
Cy=1-(BCDA(0)\&H186A0)
BCDA(0)=BCDA(0) MOD &H186A0 '&H186A0=1E5
BCDA(1)=BCDA(1)+&H186A0-BCDB(1)-Cy
Cy=1-(BCDA(1)\&H186A0)
BCDA(1)=BCDA(1) MOD &H186A0
BCDA(2)=BCDA(2)+&H186A0-BCDB(2)-Cy
Cy=1-(BCDA(2)\&H186A0)
BCDA(2)=BCDA(2) MOD &H186A0
' BCDA(3)=BCDA(3)+&H186A0-BCDB(3)-Cy
' Cy=1-(BCDA(3)\&H186A0)
' BCDA(3)=BCDA(3) MOD &H186A0
NEXT I
PRINT (TIMER-L)/Iterations;" 5-Decimal Digits:Subtraction:";
PrintBCDA(5)
'Addition Test
ClrBCD BCDB(0)
BCDB(0)=59738
BCDB(1)=00343
TIMER=L
FOR I=1 TO Iterations
BCDA(0)=BCDA(0)+BCDB(0)
Cy=BCDA(0)\&H186A0
BCDA(0)=BCDA(0) MOD &H186A0 '&H186A0=1E4
BCDA(1)=BCDA(1)+BCDB(1)+Cy
Cy=BCDA(1)\&H186A0
BCDA(1)=BCDA(1) MOD &H186A0
BCDA(2)=BCDA(2)+BCDB(2)+Cy
Cy=BCDA(2)\&H186A0
BCDA(2)=BCDA(2) MOD &H186A0
' BCDA(3)=BCDA(3)+BCDB(3)+Cy
' Cy=BCDA(3)\&H186A0
' BCDA(3)=BCDA(3) MOD &H186A0
'
BCDA(3)=CY
NEXT I
PRINT (TIMER-L)/Iterations;" 5-Decimal Digits:Addition: ";
PrintBCDA(5)
PRINT "Now Testing with 3 digits per single"
'Now do the same calc with 3 digits per SINGLE
'10MHz Tuning Word is 343,597,383,680,000
'1 Hz is 34,359,738.368
'Addition Test
ClrBCD BCDB(0)
BCDB(0)=738
BCDB(1)=359
BCDB(2)=034
TIMER=L
FOR I=1 TO Iterations
BCDA(0)=BCDA(0)+BCDB(0)
Cy=BCDA(0)\&H3E8
BCDA(0)=BCDA(0) MOD &H3E8 '&H3E8=1E3
BCDA(1)=BCDA(1)+BCDB(1)+Cy
Cy=BCDA(1)\&H3E8
BCDA(1)=BCDA(1) MOD &H3E8
BCDA(2)=BCDA(2)+BCDB(2)+Cy
Cy=BCDA(2)\&H3E8
BCDA(2)=BCDA(2) MOD &H3E8
BCDA(3)=BCDA(3)+BCDB(3)+Cy
Cy=BCDA(3)\&H3E8
BCDA(3)=BCDA(3) MOD &H3E8
BCDA(4)=BCDA(4)+BCDB(4)+Cy
Cy=BCDA(4)\&H3E8
BCDA(4)=BCDA(4) MOD &H3E8
' BCDA(5)=BCDA(5)+BCDB(5)+Cy
' Cy=BCDA(5)\&H3E8
' BCDA(5)=BCDA(5) MOD &H3E8
BCDA(5)=CY
NEXT I
PRINT (TIMER-L)/Iterations;" 3-Decimal Digits:Addition: ";
PrintBCDA(3)
END
SUB PrintBCDA(Width)
LOCAL I
PRINT "BCDA()=";
FOR I=6 TO 1 STEP -1
IF BCDA(I)<1000000 THEN
PRINT STR$(BCDA(I),Width,0,"0");",";
ELSE
PRINT STR$(BCDA(I)\1000000,1,0,"0");
PRINT STR$(BCDA(I)-(BCDA(I)\1000000) * 1000000, width-1,"0");","; ' x - (x \ 1000000) * 1000000
ENDIF
NEXT I
IF BCDA(I)<1000000 THEN
PRINT STR$(BCDA(I),Width,0,"0")
ELSE
PRINT STR$(BCDA(I)\1000000,1,0,"0");
PRINT STR$(BCDA(I)-(BCDA(I)\1000000) * 1000000, width-1,"0") ' x - (x \ 1000000) * 1000000
ENDIF
END SUB
SUB ClrBCD(Reg)
LOCAL I,J
'6 Numeric Vars per BCD register
FOR I=0 TO 6
'4 Bytes/Numeric Var
FOR J=0 TO 3
POKE VAR Reg,J,0
NEXT J
NEXT I
END SUB
The only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 10:04pm 18 Jul 2014
Copy link to clipboard
Print this post
Good work! I'm not that keep on the hex, though. Not so readable.
John
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 02:43am 19 Jul 2014
Copy link to clipboard
Print this post
@JohnS
Agree about the Hex instead of decimal, I only did it for maximum performance - I must admit I was surprised that the format of the numeric constants made a difference, but I guess that's in the nature of interpreted vs compiled code - I wonder if at the start of running, if MMBasic could/should scan the source and convert all numeric constants into internal representation for performance purposes - really help when stuff is used inside loops. I think I'll probably drop back to scientific notation since the performance hit is actually very minor when all is said and done.
WRT AD9850Controller.bas, the largest performance bottleneck is now the act of updating the AD9850 chip itself, so that's the next area to try and optimise.
Anyway thanks for all your help, really appreciated
PeterThe only Konstant is Change
boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268
Posted: 05:14am 19 Jul 2014
Copy link to clipboard
Print this post
Hi Peter,
Well done indeed. All I have to say that I seriously doubted that significant improvement will be possible. I was wrong.
Update AD9850 is another nightmare, you can't use SPI command because this old chip accepts LSB first data format only and there is no embedded command like SHIFTOUT or such in MM.
Anyway, is an updated version of AD9850 available for testing?
Regards
boss
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 05:52am 19 Jul 2014
Copy link to clipboard
Print this post
@boss
Moving up to 6 digit extended precision BCD is right at the top of my TTD list !!
So tonight or tomorrow !
Peter
The only Konstant is Change
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 12:47pm 22 Jul 2014
Copy link to clipboard
Print this post
@BobD
you asked
And I said YES. However as I complete more of my project on the uMite (so this probably doesn't matter on the Maximite), I am repeatedly hitting the Sub/Func limits of MMBasic on uMite, ie 32. So what I have had to do is revert to the LABEL:....IRETURN construct since these don't seem to count as Sub/Function's. It's not ideal but I have 4 Interrupts including a Settick, so this strategy saves 4 SUB/FUNCTIONs ! Geoff has mentioned that in the 170 release of MMBasic that he will be upping the number of allowable SUB/FUNCTIONs permitted.
So for now, ISR's are best coded as LABEL:.......IRETURN unfortunately.
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
Print this post
