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.
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 04:50am 28 Jul 2012
Copy link to clipboard
Print this post
in C:
float B = 1.0;
int A = (int) B;
in basic:
B# = 1.0
A% = int(B#)
will get the same result.
And because in Basic it is a function it is a lot slower.
And because it is interpreted it is even more slow.
If you added integer variables to MMBasic you will find dramatic speed increase, unless you have a floating point coprocessor. And because the PIC32 has no co processor anything that makes calculations easier means it is also a lot faster.
Especially when variables are used as counters and hold values from IO ports which mainly are nibble,byte and integers.
In the underlying C compiler it will often result in a register being used or a single memory address. After fetching the values it will often result in a few instruction that each can be executed in 1 clock cycle. A comparable operation with float will result in tens or hundreds of clock cycles. I would call that a dramatic increase!
Don't know where you get your knowledge from but it is certainly not from programming microcontrollers or CPU's without co-processors. Probably more in the language without types like visual basic or javascript. Completely different worlds!
Edited by TZAdvantage 2012-07-29Microblocks. Build with logic.
darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240
Posted: 05:09am 28 Jul 2012
Copy link to clipboard
Print this post
If you have problem with Basic why are you not just
doing it in C like all other do when they have to ?
Regards.
Darth.
Theory is when we know everything but nothing work ...
Practice is when everything work but no one know why ;)
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209
Posted: 05:49am 28 Jul 2012
Copy link to clipboard
Print this post
By the same reasoning, why not in assembly code.
The point is that basic is convenient to program a computer, and having integers (and byte) datatypes will greatly improve efficiency without for the programmer the need to go to a lower level language.
In my microcontroller projects i mostly use C and find that i use unsigned byte and int the most often, around 99%. Analog values are often scaled or available in sets of nibbles.
Serial ports, parallel ports, i2c, 1wire, adc, etc...
Sofar everything i connected to a microcontroller uses bytes ints and longs.
In my opinion a computer that has lots of IO like the maximite could leverage itself more if primitive datatypes like unsigned byte, int and long were available, including the bitwise operations.
It would have more variable memory avilable too. Now even a byte is stored in 32 bits, a waste of 75%. Of course you canstore more bytes in 32 bits but then you need bitwise shifts and masking making it more complicated then necessary.
This would make the need to go to C go away for almost everything.
Microblocks. Build with logic.
darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240
Posted: 07:08am 28 Jul 2012
Copy link to clipboard
Print this post
It's true
But the best to do is to ask Geoff if he is ready and
have time to change everything who use variables in the interpreter.
And up he is finish with the MM Basic v4.0 i think it will not be any
change in this direction.But no one know what it will append after
Regards.
Darth.
Theory is when we know everything but nothing work ...
Practice is when everything work but no one know why ;)
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038
Posted: 05:57am 29 Jul 2012
Copy link to clipboard
Print this post
It will speed up a lot less than you seem to think. The floating point libs already short-cut when they can easily do so, thus int(B) is much faster when B is already an integer than when it isn't.
You always have the interpreter overhead with the above, so you can slightly reduce the slowness overall. (Obviously the interpreter will get much bigger and more complex.)
I am very doubtful this is really a wise way to go but by all means try it. The source code is available and if you get a major speed increase I expect Geoff would be willing to consider folding the code or its ideas into a future version.