Introduction to BBC BASIC

[DavidS]

If I decide to start a BBC BASIC to BBC BASIC Performance Comparison how many will contrbute for the 4 versions of BBC BASIC?

My versions of BBC BASIC have never been particularly fast. I have concentrated on expanding the capabilities of the language, with speed a lower priority. Recently my efforts have been directed to improving the cross-platform credentials of the language, and that has necessarily involved compiling from C source rather than from assembler code, which has probably roughly halved the speed again.

Raw interpreter speed is rarely a factor these days, many programs are input/output bound, i.e. the limiting factor in speed is things like the speed with which graphics can be rendered or data read from a disk or the network. Python is not a particularly fast language either, yet that doesn't stop it being incredibly popular.

So I have no interest in any 'performance' comparisons; I can tell you now that my versions would come out the slowest. But whilst Sophie's ARM BASIC may be fast, by modern standards it's primitive. I couldn't write programs without structures, private variables, indirect function calls, long strings and all the other language enhancements that my versions have.

The only of those features we are missing is structures, and we can fake that using indirection.

Ok I accept the lack of interest in speed. Many applications do not need it do to I/O as you say. So I guess that your version is not the one to use to write a SceneDemo, or full blown modern fully software polygon rendering textured mapped 3D FPS (both possible on RISC OS in BBC BASIC thanks to its speed). I wounder how Brandy BASIC fairs.

[John_Spikowski]

I could bring back the Brandy extension module and you could include it in your comparisons of BBC BASIC like variations.

[DavidS]

I could bring back the Brandy extension module and you could include it in your comparisons of BBC BASIC like variations.

Sounds good to me. Is ScriptBasic generally fast?

[John_Spikowski]

Give it a try and see for yourself.

Whatever isn"t fast enough, create a C extension module for it.

[DavidS]

Give it a try and see for yourself.

Whatever isn"t fast enough, create a C extension module for it.

Can not do. I do not currently have the SDL 1.2 development libraries for RISC OS on my system, so a no go on compiling ScriptBasic.

Perhaps we should give this thread back to RichardRussells BBC BASIC.

[RichardRussell]

The only of those features we are missing is structures, and we can fake that using indirection.

All the features I listed are "missing" from ARM BASIC, otherwise I wouldn't have had to add them, would I?! And indirection is no substitute for structures (it's the best workaround available, but not comparable with the real thing).

There do seem to be two kinds of BBC BASIC enthusiast. There are those who seem to enjoy the 'retro' nature of a 30+ year old BASIC lacking many features that would be considered essential in a modern language today, and finding what workarounds they can for those shortcomings. And there are those who set out to enhance BBC BASIC so that it can compete with modern languages on their own terms without workarounds. I am firmly in the latter camp.

I guess that your version is not the one to use to write a SceneDemo, or full blown modern fully software polygon rendering textured mapped 3D FPS (both possible on RISC OS in BBC BASIC thanks to its speed).

It's great that ARM BASIC is fast enough to do "fully software polygon rendered texture mapped 3D" but these days all modern computers have GPUs (Graphics Processing Units) which can do that far more quickly than the fastest CPU code can, and BBC BASIC for SDL 2.0 provides access to the GPU via SDL. So, despite my BASICs being slower, they can easily outperform ARM BASIC's software rendering that way. Here's an example.

[John_Spikowski]

Wow Richard!

That is an amazing simulation.

[RichardRussell]

Wow Richard!
That is an amazing simulation.

I can't take much credit for it, the shader code was originally written by somebody else and tweaked by me. But it illustrates that when you can take advantage of the GPU to do the graphics 'heavy lifting' you don't need high performance from the controlling program, which in this case is written in BBC BASIC. ScriptBasic would be able to do exactly the same thing if you provided a GPU extension (or is there already one?).

You can think of it as the modern equivalent of combining BASIC with assembler code. BBC BASIC is of course known for incorporating an assembler in the runtime engine, which makes it particularly easy to write hybrid programs with the control code in BASIC and the time-critical (typically graphics) code in assembler. But that makes the program CPU-dependent and non-portable, which is highly undesirable.

Shader code, for running on the GPU, has fortunately been standardised and exactly the same code will run on Windows, MacOS, Linux (including Raspbian), Android and iOS. If you have an Android or iOS cellphone you can get BBC BASIC for it and that Seascape program is one of the supplied examples. If the device is relatively recent it should run at full frame rate.

[ZXDunny]

What's really nice is that the shader code is contained within the BBC BASIC program, rather than loaded as an external resource

I'm firmly in the 256-colours only camp and will never add OpenGL to my BASIC, but Richard's work is exceptional.

[John_Spikowski]

but Richard's work is exceptional.

+1

[Heater]

Awesome!

That is not your grandmothers BASIC!

[DavidS]

Very nice Richard.

I agree with much of what you say. I have been pushing for Structures in BBC BASIC V/VI for a long time. I have also been pushing for an OpenGL module for RISC OS that exports an SWI interface so we can use it from the likes of BBC BASIC.

Indirection of procedures has long been in BBC BASIC (compiled only).

Again we are missing structures.

Long strings are easy in BBC BASIC, and I am guessing that you have a different meaning of private variables than me on this (because we have always had local variables, and BBC BASIC is procedural not OO).

[RichardRussell]

I am guessing that you have a different meaning of private variables than me

I use the PRIVATE keyword to signify what in C would be called 'static' (I felt that STATIC was too obscure a term for a beginner). Both LOCAL and PRIVATE variables are 'local' to the FN/PROC in which they are declared, but whereas LOCAL variables 'forget' their values between one call and the next, PRIVATEs don't:

Code: Select all

      FOR i = 1 TO 10
        PROC1
      NEXT
      END

      DEF PROC1
      LOCAL a
      PRIVATE b
      a += 1
      b += 1
      PRINT a, b
      ENDPROC

which produces:

Code: Select all

         1         1
         1         2
         1         3
         1         4
         1         5
         1         6
         1         7
         1         8
         1         9
         1        10
>

Without the PRIVATE functionality, the only way to code it is to make 'b' a global variable, visible to (and modifiable by) the rest of the program, which is obviously undesirable, especially in a language that claims to be 'structured' like BBC BASIC. I've not done a great deal of C programming but when switching back to BASIC it was one of the features I missed the most, so I added it! You can of course have PRIVATE arrays and structures (and arrays of structures) too.

[John_Spikowski]

ScriptBasic takes it another level with name spaces. (MODULE) By default all variables (except function arguments) are global unless you define LOCAL variable usage with a function/ sub.

If you wish there is a ScriptBasic option to declare all function/sub variables as local by default.

[RichardRussell]

ScriptBasic takes it another level with name spaces.

Brandy BASIC has that functionality (or at least is documented to have, I've never tried it) using the LIBRARY LOCAL statement. But it's the only version of BBC BASIC that does, so it's rather an outlier in that respect and if you use the feature you tie your code to Brandy.

[Soruk]

Here's a simple program to try on any BASIC that has floating-point variables with 64-bits or more:

Code: Select all

      a = 2^50 + 0.5
      b = INT(a)
      PRINT a - b

This should print '0.5'. If it doesn't I would say something is seriously wrong.

I've been having more thoughts about this. And, while it deviates from RISC OS (and BBC Micro) BBC BASIC, I've added a run-time switch to Matrix Brandy to enable this behaviour of allowing INT() to process a number that can't be stored in a standard 32-bit integer variable. With the latest commit, running

Code: Select all

SYS "Brandy_INTusesFloat",1

will enable the above code snippet to run, and gives the correct answer of 0.5. Set it to 0 to revert to the default behaviour.

[RichardRussell]

I've been having more thoughts about this. And, while it deviates from RISC OS (and BBC Micro) BBC BASIC, I've added a run-time switch to Matrix Brandy to enable this behaviour of allowing INT() to process a number that can't be stored in a standard 32-bit integer variable.

Thanks. Naturally I think it should be the default state rather than an option, but I appreciate that Brandy strives to be compatible with Acorn's BASICs, warts and all. Am I right in thinking that this switch will only change the behaviour in circumstances when Acorn's BASIC would report a 'Number too big' error? In other words only when an existing program traps and acts upon the error could it conceivably affect compatibility?

What is your current opinion on the other anomaly you highlighted, of this code printing '2' in Acorn versions of BBC BASIC:

Code: Select all

      PRINT -2147483647 - 2147483647

Although in my judgement this is clearly 'wrong', and my BASICs don't do it (they print -4294967294), because no error is reported it is possible that existing programs could be affected if you 'correct' Matrix Brandy. Since my versions have been 'incompatible' in this regard right back to BBC BASIC (Z80) in 1982 it doesn't worry me in the least, but you are in a more difficult position. How far should the 'warts and all' principle be taken?!

[Soruk]

I've been having more thoughts about this. And, while it deviates from RISC OS (and BBC Micro) BBC BASIC, I've added a run-time switch to Matrix Brandy to enable this behaviour of allowing INT() to process a number that can't be stored in a standard 32-bit integer variable.

Thanks. Naturally I think it should be the default state rather than an option, but I appreciate that Brandy strives to be compatible with Acorn's BASICs, warts and all. Am I right in thinking that this switch will only change the behaviour in circumstances when Acorn's BASIC would report a 'Number too big' error? In other words only when an existing program traps and acts upon the error could it conceivably affect compatibility?

No, it toggles two different code paths, one is the (corrected) original one that pulls the float from the stack, runs TOINT() (which floor()s the number, then casts it to a signed 32-bit integer) on it and pushes it to the stack as an int. The new one pulls the float from the stack, runs floor() on it and pushes it back as a float. While this second path is certainly different to Acorn's BASICs, is why I've made it a non-default switchable option so without toggling it it'll behave the same as it would on Acorn's BASICs.

I guess there's the element of trying not to surprise the user, with it doing something other than what they would expect.

What is your current opinion on the other anomaly you highlighted, of this code printing '2' in Acorn versions of BBC BASIC:

Code: Select all

      PRINT -2147483647 - 2147483647

Hmm. I didn't mean that, it was an upstream Brandy BASIC bug. It's fixed on Matrix Brandy, and also gives correct answers (-4294967294) on my (emulated) BBC Master and RiscPC. So, no compatibility issues to worry about there!

Edit: Talking rubbish due to unable to type long numbers accurately!

[ejolson]

I've been having more thoughts about this. And, while it deviates from RISC OS (and BBC Micro) BBC BASIC, I've added a run-time switch to Matrix Brandy to enable this behaviour of allowing INT() to process a number that can't be stored in a standard 32-bit integer variable.

Thanks. Naturally I think it should be the default state rather than an option, but I appreciate that Brandy strives to be compatible with Acorn's BASICs, warts and all. Am I right in thinking that this switch will only change the behaviour in circumstances when Acorn's BASIC would report a 'Number too big' error? In other words only when an existing program traps and acts upon the error could it conceivably affect compatibility?

No, it toggles two different code paths, one is the (corrected) original one that pulls the float from the stack, runs TOINT() (which floor()s the number, then casts it to a signed 32-bit integer) on it and pushes it to the stack as an int. The new one pulls the float from the stack, runs floor() on it and pushes it back as a float. While this second path is certainly different to Acorn's BASICs, is why I've made it a non-default switchable option so without toggling it it'll behave the same as it would on Acorn's BASICs.

I guess there's the element of trying not to surprise the user, with it doing something other than what they would expect.

What is your current opinion on the other anomaly you highlighted, of this code printing '2' in Acorn versions of BBC BASIC:

Code: Select all

      PRINT -2147483647 - 2147483647

Hmm. I didn't mean that, it was an upstream Brandy BASIC bug. It's fixed on Matrix Brandy, and also gives correct answers on my (emulated) BBC Master and RiscPC. So, no compatibility issues to worry about there!

Pardon my ignorance, but did Acorn's Basics default to single or double precision floating point?

[Soruk]

Pardon my ignorance, but did Acorn's Basics default to single or double precision floating point?

I believe that all of them, with the exception of BASIC VI on RISC OS (softloaded on Archimedes and RiscPC machines) they're all single precision 40-bit. BASIC VI offered 64-bit floating point (instead of 40-bit, you couldn't do 40-bit FP on BASIC VI) at the cost of being slightly slower.

[ejolson]

Pardon my ignorance, but did Acorn's Basics default to single or double precision floating point?

I believe that all of them, with the exception of BASIC VI on RISC OS (softloaded on Archimedes and RiscPC machines) they're all single precision 40-bit. BASIC VI offered 64-bit floating point (instead of 40-bit, you couldn't do 40-bit FP on BASIC VI) at the cost of being slightly slower.

It seems 32-bit integers were more compatible with 40-bit floating point. Perhaps when the precision of the floating point increases so too should the size of the default integer type.

[RichardRussell]

No, it toggles two different code paths, one is the (corrected) original one that pulls the float from the stack, runs TOINT() (which floor()s the number, then casts it to a signed 32-bit integer) on it and pushes it to the stack as an int. The new one pulls the float from the stack, runs floor() on it and pushes it back as a float.

I don't know how Brandy works internally (and I don't want to!) but if setting your new switch changes what is returned from INT even if it fits in a 32-bit integer isn't that potentially rather worrying? The way my BASICs work is that INT returns a float (containing an integer value) only if it won't fit in an integer register; if it will fit in an integer register it returns a true integer. That's the change I would have expected you to have made, and it's the change that ought to be free of any compatibility issues apart from the rare case of a program trapping the 'Number too big' error.

I guess there's the element of trying not to surprise the user, with it doing something other than what they would expect.

That's exactly my point. If the user expects that INT will return a 32-bit integer isn't that what the modified code (with the switch enabled) should also do, when the number is in range? You seem to be giving the programmer a choice between returning a true integer but throwing a 'Number too big' error when out of range, or returning a float always, neither of which is ideal.

It's not as though it's difficult to do what I think is the optimum solution. In my C implementation I use floorl() to return the next lowest integer and then I cast the result to a 64-bit integer. If the cast returns the same value, it fits; if not, it doesn't. A 32-bit equivalent would be something like:

Code: Select all

    double f = floor(v) ;
    int n = f ; // cast
    if (n == f)
      // result is the integer n
    else
      // result is the double f

I didn't mean that, it was an upstream Brandy BASIC bug. It's fixed on Matrix Brandy, and also gives correct answers on my (emulated) BBC Master and RiscPC. So, no compatibility issues to worry about there!

Your idea of "correct answers" is different from mine! I feel quite strongly that the 'correct' result from -2147483247 - 2147483647 is -4294967294, not 2, especially as the former value is within the range of integers that can be represented precisely in all versions of BBC BASIC. Returning 2 seems perverse to me (I know why it happens, because of 32-bit 'wraparound', but this is BASIC we're talking about not machine code!). It's a particularly nasty behaviour because it can happen 'silently' in the middle of a complicated expression evaluation, and you may not realise it.

But maybe I'm the exception here. Clearly Acorn thought it acceptable and you also think it's acceptable. What do others think?

[RichardRussell]

did Acorn's Basics default to single or double precision floating point?

Did you miss this comment in which I enquired whether your test for precision in the classic BASIC Fibo might be confused because BBC BASIC uses neither 32-bit ('single') nor 64-bit ('double') precision but 40-bits? It's a nice floating-point format because it has about 10 significant decimal digits of precision, and has a larger 'integer' range than the machine's native (32-bit) integer type, so you can always transfer an integer into and out of a float losslessly.

[Soruk]

No, it toggles two different code paths, one is the (corrected) original one that pulls the float from the stack, runs TOINT() (which floor()s the number, then casts it to a signed 32-bit integer) on it and pushes it to the stack as an int. The new one pulls the float from the stack, runs floor() on it and pushes it back as a float.

I don't know how Brandy works internally (and I don't want to!) but if setting your new switch changes what is returned from INT even if it fits in a 32-bit integer isn't that potentially rather worrying? The way my BASICs work is that INT returns a float (containing an integer value) only if it won't fit in an integer register; if it will fit in an integer register it returns a true integer. That's the change I would have expected you to have made, and it's the change that ought to be free of any compatibility issues apart from the rare case of a program trapping the 'Number too big' error.

I guess there's the element of trying not to surprise the user, with it doing something other than what they would expect.

That's exactly my point. If the user expects that INT will return a 32-bit integer isn't that what the modified code (with the switch enabled) should also do, when the number is in range? You seem to be giving the programmer a choice between returning a true integer but throwing a 'Number too big' error when out of range, or returning a float always, neither of which is ideal.

It's not as though it's difficult to do what I think is the optimum solution. In my C implementation I use floorl() to return the next lowest integer and then I cast the result to a 64-bit integer. If the cast returns the same value, it fits; if not, it doesn't. A 32-bit equivalent would be something like:

Code: Select all

    double f = floor(v) ;
    int n = f ; // cast
    if (n == f)
      // result is the integer n
    else
      // result is the double f

I didn't mean that, it was an upstream Brandy BASIC bug. It's fixed on Matrix Brandy, and also gives correct answers on my (emulated) BBC Master and RiscPC. So, no compatibility issues to worry about there!

Your idea of "correct answers" is different from mine! I feel quite strongly that the 'correct' result from -2147483247 - 2147483647 is -4294967294, not 2, especially as the former value is within the range of integers that can be represented precisely in all versions of BBC BASIC. Returning 2 seems perverse to me (I know why it happens, because of 32-bit 'wraparound', but this is BASIC we're talking about not machine code!). It's a particularly nasty behaviour because it can happen 'silently' in the middle of a complicated expression evaluation, and you may not realise it.

But maybe I'm the exception here. Clearly Acorn thought it acceptable and you also think it's acceptable. What do others think?

I'll address the int casting in a code update. Regarding the -2147483247 - 2147483647 is -4294967294, not 2 thing, the Acorn BASICs all return -4294967294, only the older Brandy BASIC (and earlier unfixed Matrix Brandy) returned 2.

(Edit: Code update pushed to git)

[RichardRussell]

Acorn BASICs all return -4294967294, only the older Brandy BASIC (and earlier unfixed Matrix Brandy) returned 2.

When you say "all" which versions do you mean precisely? My genuine BBC Master, running BASIC 4 ("(C)1984 Acorn") returns 2, BeebEm emulating BASIC 2 ("(C)1982 Acorn") returns 2 and Red Squirrel emulating "ARM BBC BASIC V version 1.19 (C) Acorn 1989" also returns 2. So I think your "all" is at best an exaggeration!