Re: Why Avoid BASIC on RPi?
@scruss:
Also I would be interested in how fast it runs in Brandy on a 3B, with default clocking?
I do not have a 3B+, so I can not compare the results on like hardware.
Also I would be interested in how fast it runs in Brandy on a 3B, with default clocking?
I do not have a 3B+, so I can not compare the results on like hardware.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
If nothing else it inspired me to install FreeBASIC on my Pi 3B, which was an entirely painless venture thanks to scruss's instructions here -
http://scruss.com/blog/2015/03/25/runni ... spberry-pi
The build took just over 4 minutes on a Pi 3B. Coming back to it after some time away means I can treat it as the language it is, and it seems pretty good with just a quick play. I guess we can start the Basic Wars now as to which is best and which everyone should be using

Re: Why Avoid BASIC on RPi?
LOL, I remember the days of the BASIC Wars, I also remember the System Wars (Amiga vs Atari ST vs Macintosh vs Archimedes), the fodder of Demo codinghippy wrote: ↑Wed Nov 21, 2018 2:29 pmIf nothing else it inspired me to install FreeBASIC on my Pi 3B, which was an entirely painless venture thanks to scruss's instructions here -
http://scruss.com/blog/2015/03/25/runni ... spberry-pi
The build took just over 4 minutes on a Pi 3B. Coming back to it after some time away means I can treat it as the language it is, and it seems pretty good with just a quick play. I guess we can start the Basic Wars now as to which is best and which everyone should be using![]()

Actually this thread has inspired me to get booted into Raspbian, update, compile RPCEmu (so I still have RISC OS), compile FreeBASIC, and transfor all of my OS development over to the Linux system (using the Linux version of gcc, and one of the Linux BBC-BASICs for the assembly).
Have you tried the Fibinacci to a million base10 places in FreeBASIC yet?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
Talking about memory usage, I see that BBC Basic V (brandy) is very small compared to the other interpreters.
214KB Got to be a good thing!
To run a simple hello world program you have to load the interpreter first:
214KB Got to be a good thing!
To run a simple hello world program you have to load the interpreter first:
Code: Select all
Assembler 0.3KB
C 5.3KB
BASIC 214KB
python2 3.1MB
python3 3.8MB
Javascript 15.0MB
Re: Why Avoid BASIC on RPi?
BBC BASIC on RISC OS is even smaller, and in the ROM image so no added memory.jahboater wrote: ↑Wed Nov 21, 2018 2:54 pmTalking about memory usage, I see that BBC Basic V (brandy) is very small compared to the other interpreters.
214KB Got to be a good thing!
To run a simple hello world program you have to load the interpreter first:Code: Select all
Assembler 0.3KB C 5.3KB BASIC 214KB python2 3.1MB python3 3.8MB Javascript 15.0MB
Though what about compiled BASIC? With the correct command line options FreeBASIC can produce a smaller version.
BTW: Assembler should either be 35 bytes (~0.035KB) or if you are counting the interpreter, 35 bytes plus the code in the OS to display the string.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
Thank you. Though the 3B+ is notably faster than the 3B. It would be nice to see on a 3B what it is.
Though now that I am inside of Linux on my 3B I could just install Brandy and see for myself.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
If its compiled there is no need to load an interpreter. Should be pretty small.
My asm program is just this - the executable is actually 352 bytes (probably just the ELF overhead)
Code: Select all
.global _start
_start:
mov r0,#1
ldr r1,=str
mov r2,#13
mov r7,#4
svc 0 // write
mov r0,#0
mov r7,#1
svc 0 // exit
str:
.ascii "Hello, world\n"
Same applies the graphics library I presume.
Re: Why Avoid BASIC on RPi?
Yes the ELF overhead can be greater, if allowed to be. Though you will likely save a good bit just by using the older a.out format (not file name, actual file format), as it has less overhead, assuming that Linux still supports it (last I checked Linux still did).jahboater wrote: ↑Wed Nov 21, 2018 3:14 pmIf its compiled there is no need to load an interpreter. Should be pretty small.
My asm program is just this - the executable is actually 352 bytes (probably just the ELF overhead)Code: Select all
.global _start _start: mov r0,#1 ldr r1,=str mov r2,#13 mov r7,#4 svc 0 // write mov r0,#0 mov r7,#1 svc 0 // exit str: .ascii "Hello, world\n"
I never could get used to seeing people using svc where you expect to see SWI.
Graphics Library? BBC BASIC V does have builtin graphics commands, though they are built into the interpreter, no external library needed.I see what you mean about the small size on RISC OS because the interpreter is included in the OS kernel and doesn't have to be loaded first.
Same applies the graphics library I presume.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
Not sure how you do that. "ld hello.o" creates an a.out file in ELF format! There used to be something called superstrip that could remove most of the ELF sections and still leave the program executable.DavidS wrote: ↑Wed Nov 21, 2018 3:30 pmYes the ELF overhead can be greater, if allowed to be. Though you will likely save a good bit just by using the older a.out format (not file name, actual file format), as it has less overhead, assuming that Linux still supports it (last I checked Linux still did).
Superstrip "sstrip" gets the hello world program down to 135 bytes!
Re: Why Avoid BASIC on RPi?
I do not remember the ld command line well enough. Though there should be switch for the output format, that would be used to specify what format to put it into.jahboater wrote: ↑Wed Nov 21, 2018 3:44 pmNot sure how you do that. "ld hello.o" creates an a.out file in ELF format! There used to be something called superstrip that could remove most of the ELF sections and still leave the program executable.DavidS wrote: ↑Wed Nov 21, 2018 3:30 pmYes the ELF overhead can be greater, if allowed to be. Though you will likely save a good bit just by using the older a.out format (not file name, actual file format), as it has less overhead, assuming that Linux still supports it (last I checked Linux still did).
Superstrip "sstrip" gets the hello world program down to 135 bytes!
135 bytes is pretty good for an ELF.
I think there are still a few threads floating around somewhere about how to manually code an ELF and save a huge amount on the filesize.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
Ok it apears that the current binutils in Raspbian do not support a.out format. Just looked at the documentation to remember how to find the supported file formats, and then looked at the supported file formats.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
Does anyone know if DavidS' Fibo(4784969) actually produces the correct result?
It does not output even a small part of the result for verification.
Can't compare timings until we know it is correct.
It does not output even a small part of the result for verification.
Can't compare timings until we know it is correct.
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
If you want to know if it is correct or not 3 ways:
1 : verify the algorithm.
2 : write a procedure to HEX-dump the accumulated value (31-bits in each element of the array, lowest 31 bits in element 0) to the display, and check it against another.
3 : Take a known correct calculation, that is stored in the same manner, and compare it in the program.
I was hoping that someone would have done #1, as that should be enough as long as the person knows BBC BASIC V well enough.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
What's the problem? Just print the result, in normal decimal, like everyone else that took up the challenge.
Until then then it does qualify.
Until then then it does qualify.
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
Unfortunately that is one thing that is not quite as simple in BASIC (or C, or Pascal). Though to print it in hex would be easy enough.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
@Heater:
Are you saying there is something wrong with my implementation of the algorithm? If so what is the issue so that I can correct it?
Are you saying there is something wrong with my implementation of the algorithm? If so what is the issue so that I can correct it?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
Re: Why Avoid BASIC on RPi?
What do you mean, in C it's easy:
Code: Select all
#include <stdio.h>
#include <gmp.h>
#include <time.h>
int main( void )
{
mpz_t res;
mpz_init( res );
double startTime = (float)clock()/CLOCKS_PER_SEC;
mpz_fib_ui( res, 4784969 );
double endTime = (float)clock()/CLOCKS_PER_SEC;
double timeElapsed = endTime - startTime;
gmp_printf( "%Zd\n", res );
printf("%f\n", timeElapsed);
}
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
For interest/amusement - printing seems to be more costly than executing it:-
Code: Select all
$ ./fibo >/dev/null
Exec time = 41 ms, Print time = 153 ms
$
Re: Why Avoid BASIC on RPi?
DavidS,
What I'm saying is that I have no idea if it produces a correct result or not. Which is kind of fundamental to such a benchmark.
Now, you did say there were ways for us to deal with this:
1 : verify the algorithm.
This is not really possible unless you have a formal definition of the language I can read. And a formal proof that your interpretter does the right thing according to that definition. And I'm crazy enough to waste my life checking all that.
2 : write a procedure to HEX-dump the accumulated value (31-bits in each element of the array, lowest 31 bits in element 0) to the display, and check it against another.
Hmm.. perhaps. But that should be part of your program as a response to the challenge. I'm not about to spend time on it.
3 : Take a known correct calculation, that is stored in the same manner, and compare it in the program.
I suspect there is no such thing. And anyway see 2) above.
No, the onus is on you, the program author, do demonstrate the programs correctness. Just print the result in decimal like everyone else.
No, I am not.Are you saying there is something wrong with my implementation of the algorithm?
What I'm saying is that I have no idea if it produces a correct result or not. Which is kind of fundamental to such a benchmark.
Now, you did say there were ways for us to deal with this:
1 : verify the algorithm.
This is not really possible unless you have a formal definition of the language I can read. And a formal proof that your interpretter does the right thing according to that definition. And I'm crazy enough to waste my life checking all that.
2 : write a procedure to HEX-dump the accumulated value (31-bits in each element of the array, lowest 31 bits in element 0) to the display, and check it against another.
Hmm.. perhaps. But that should be part of your program as a response to the challenge. I'm not about to spend time on it.
3 : Take a known correct calculation, that is stored in the same manner, and compare it in the program.
I suspect there is no such thing. And anyway see 2) above.
No, the onus is on you, the program author, do demonstrate the programs correctness. Just print the result in decimal like everyone else.
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
Has anyone checked the correctness of the results?
I suggest the C library function result is the most plausible.
But I don't want to publish a million digits here given the current server problems
I suggest the C library function result is the most plausible.
But I don't want to publish a million digits here given the current server problems

Re: Why Avoid BASIC on RPi?
jahboater,
My C version:
Thirty odd milliseconds to calculate. One third of a second to print the result.
It's even worse for my JS and Python versions.
BASIC can't do it at all !
Yep. All that binary to decimal conversion takes a long time:...printing seems to be more costly than executing it...
My C version:
Code: Select all
$ time ./fibo
...
6330930391815964864885353407167474856539211500699706378405156269
0.031250
real 0m0.283s
user 0m0.141s
sys 0m0.047s
It's even worse for my JS and Python versions.
BASIC can't do it at all !
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
Yes its only necessary to print the last few digits I think to confirm correctness.
Re: Why Avoid BASIC on RPi?
jahboater,
The C versions we have just call a fibo function in the gmp library. I have no way to know how plausible that result is. Who knows what bugs are in there?
But we have solutions presented in Python and Javascript that do the algorithm themselves. Albeit the big integer maths is done by the languages in question. At least we can see we have the right algorithm there.
However, all these efforts agree on the result. Computed in very different ways. So we can be very confident now that we know what fibo(4784969) is.
The BASIC solution is the only fail here so far.
No, the servers are struggling because I post so much
We could just present the end of the million digits, as seen above. Better would be to present the md5sum or sha hash of the result. Much smaller and unlikely to be wrong. Good luck doing that in BASIC.
That's an interesting statement.I suggest the C library function result is the most plausible.
The C versions we have just call a fibo function in the gmp library. I have no way to know how plausible that result is. Who knows what bugs are in there?
But we have solutions presented in Python and Javascript that do the algorithm themselves. Albeit the big integer maths is done by the languages in question. At least we can see we have the right algorithm there.
However, all these efforts agree on the result. Computed in very different ways. So we can be very confident now that we know what fibo(4784969) is.
The BASIC solution is the only fail here so far.
Ha!But I don't want to publish a million digits here given the current server problems
No, the servers are struggling because I post so much

We could just present the end of the million digits, as seen above. Better would be to present the md5sum or sha hash of the result. Much smaller and unlikely to be wrong. Good luck doing that in BASIC.
Memory in C++ is a leaky abstraction .
Re: Why Avoid BASIC on RPi?
Well that might be possible, to do in a reasonable amount of time. Even in C.
Ok in a bit I will throw together a version that prints the last few digits so that it can be verified. I will translate to C as I am at a Linux System at the moment (or maybe I will do the reasonable thing and just pop back to RISC OS, add the code to take the lower portion 124 bits of the result and print it out).
@Heater:
There is nothing in BBC BASIC V on RISC OS that is going to act strange in this program, as should be known by anyone familiar with using the language (as would be most RISC OS users), though if you really want to also do as you said you are crazy enough to do then the BBC BASIC V manual for RISC OS is at:
http://www.riscos.com/support/developers/bbcbasic/
And you can find stronghelp format manual that covers BASIC in detail (including internal memory locations, etc) at:
http://www.kappa.me.uk/basic.htm
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers.