Why Avoid BASIC on RPi?

[DavidS]

@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.

[hippy]

I do thank everyone for the positive participation in this thread.

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

[DavidS]

I do thank everyone for the positive participation in this thread.

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

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 coding .

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?

[jahboater]

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:

Code: Select all

Assembler   0.3KB
C           5.3KB
BASIC       214KB
python2     3.1MB
python3     3.8MB
Javascript 15.0MB

[jahboater]

@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.

On my 3B+ it says 25.35 seconds.

brandy -size 100m --load fibo.bas

[DavidS]

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:

Code: Select all

Assembler   0.3KB
C           5.3KB
BASIC       214KB
python2     3.1MB
python3     3.8MB
Javascript 15.0MB

BBC BASIC on RISC OS is even smaller, and in the ROM image so no added memory.

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.

[DavidS]

@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.

On my 3B+ it says 25.35 seconds.

brandy -size 100m --load fibo.bas

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.

[jahboater]

Though what about compiled BASIC? With the correct command line options FreeBASIC can produce a smaller version.

If its compiled there is no need to load an interpreter. Should be pretty small.

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.

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 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.

[DavidS]

Though what about compiled BASIC? With the correct command line options FreeBASIC can produce a smaller version.

If its compiled there is no need to load an interpreter. Should be pretty small.

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.

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"

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).

I never could get used to seeing people using svc where you expect to see SWI.

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.

Graphics Library? BBC BASIC V does have builtin graphics commands, though they are built into the interpreter, no external library needed.

[jahboater]

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).

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.

Superstrip "sstrip" gets the hello world program down to 135 bytes!

[DavidS]

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).

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.

Superstrip "sstrip" gets the hello world program down to 135 bytes!

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.

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.

[DavidS]

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.

[Heater]

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.

[DavidS]

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.

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.

[Heater]

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.

[DavidS]

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.

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.

[DavidS]

@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?

[Heater]

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);
}

[jahboater]

Just print the result, in normal decimal, like everyone else that took up the challenge.

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
$ 

C fibo function version on Intel PC

[Heater]

DavidS,

Are you saying there is something wrong with my implementation of the algorithm?

No, I am not.

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.

[jahboater]

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

[Heater]

jahboater,

...printing seems to be more costly than executing it...

Yep. All that binary to decimal conversion takes a long time:

My C version:

Code: Select all

$ time ./fibo
...
6330930391815964864885353407167474856539211500699706378405156269
0.031250

real    0m0.283s
user    0m0.141s
sys     0m0.047s

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 !

[jahboater]

Yes its only necessary to print the last few digits I think to confirm correctness.

[Heater]

jahboater,

I suggest the C library function result is the most plausible.

That's an interesting statement.

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.

But I don't want to publish a million digits here given the current server problems

Ha!

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.

[DavidS]

Yes its only necessary to print the last few digits I think to confirm correctness.

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