BBC Basic

[DavidS]

RISC OS is available for the RPi, one of the two main OS's available, and BBC BASIC V is an integral part of RISC OS.

Whilst true, switching from Linux to RISC OS simply to be able to run BBC BASIC is a somewhat drastic step! And of course BBC BASIC V is a 30-year-old language lacking modern features (even to the extent of strings being limited to a maximum length of 255 characters, which is bordering on the ridiculous in 2017).

My recently released, albeit 'experimental', edition of BBC BASIC for Raspbian Jessie has all the bells and whistles of BBC BASIC for Windows, including data structures, an EXIT statement, PRIVATE variables, huge strings, event interrupts, an 'address of' operator, byte variables and arrays, a line continuation character and indirect procedure and function calls.

Richard.

Since when is BBC BASIC V limited to 255 byte arrays? While a string type may only be 255 characters, a byte array that can be used for storing a longer string can be as big as you dare to make it.

The only good thing about the BBC BASIC for Windows is the structured data types, otherwise it is a poor attempt at making BBC BASIC OO, and a good job of breaking compatibility with standard features of BBC BASIC V.

What use is a PRIVATE variable in a purely procedural language?

What use are interrupts in BBC BASIC? You can already do everything the OS allows for (except for handling real SWI's and interrupts) in pure BBC BASIC. You can also handle interrupts and SWI's in code written in BBC BASIC by mixing in assembly (something missing from newer implementations), and loading the code as a module that can communicate with your BASIC program (I would like to see an example of BBC BASIC for Windows doing that [or the equivalent of providing WDM model driver interface], while remaining an interpreted language).

[RichardRussell]

Since when is BBC BASIC V limited to 255 byte arrays?

I was not referring to arrays but to strings. All versions of BBC BASIC from the Acorn stable have had a maximum string length of 255 characters. Brandy has a maximum string length of 65535 characters. BB4W (v6) and BBCSDL strings are limited only by available memory.

As far as byte arrays are concerned, only BB4W and BBCSDL have them! All other versions of BBC BASIC support only numeric arrays (floating point or integer) and string arrays. But byte arrays, even when available, are no substitute for strings because they don't have automatic storage allocation and once created their length cannot be changed.

it is a poor attempt at making BBC BASIC OO, and a good job of breaking compatibility with standard features of BBC BASIC V.

Since no versions of BBC BASIC are Object Oriented (it's a procedural language) I don't see what relevance OO has at all. As far as compatibility is concerned, the compatibility of BB4W and BBCSDL with BASIC V is pretty good. What particular compatibility issues concern you?

What use is a PRIVATE variable in a purely procedural language?

C has private (static) variables, and it's a procedural language. Without them you are forced to use globals for anything that is local in scope but needs to be preserved from one call to the next.

What use are interrupts in BBC BASIC?

Are you kidding? Most modern operating systems are event-driven so a programming language needs to have a mechanism for receiving those events asynchronously. The only alternative is an old-fashioned polling loop which is hopelessly inefficient and limiting.

You can also handle interrupts and SWI's in code written in BBC BASIC by mixing in assembly (something missing from newer implementations)

What do you mean by "missing from newer implementations"? Brandy is the only version of BBC BASIC without an integral assembler, isn't it?

I would like to see an example of BBC BASIC for Windows doing that

BBC BASIC for Windows can handle callbacks, if that is what you are referring to. There's a library for it, see the online documentation.

Richard.

[DavidS]

Since when is BBC BASIC V limited to 255 byte arrays?

I was not referring to arrays but to strings. All versions of BBC BASIC from the Acorn stable have had a maximum string length of 255 characters. Brandy has a maximum string length of 65535 characters. BB4W (v6) and BBCSDL strings are limited only by available memory.

As far as byte arrays are concerned, only BB4W and BBCSDL have them! All other versions of BBC BASIC support only numeric arrays (floating point or integer) and string arrays. But byte arrays, even when available, are no substitute for strings because they don't have automatic storage allocation and once created their length cannot be changed.

First thing you can easily do an array of integers, and use it as a string in BBC BASIC V (aka ARM BASIC), it is done all the time, and has no limit on the length. You can use a allocated memory array for any type including bytes, which is a big part of BBC BASIC V programming. So I do not know where you get that only BB4W and BBCSDL support byte arrays, simply not true.

it is a poor attempt at making BBC BASIC OO, and a good job of breaking compatibility with standard features of BBC BASIC V.

Since no versions of BBC BASIC are Object Oriented (it's a procedural language) I don't see what relevance OO has at all. As far as compatibility is concerned, the compatibility of BB4W and BBCSDL with BASIC V is pretty good. What particular compatibility issues concern you?

It has been a god while since I looked at BBC BASIC for Windows, though last I did I remember that they did not support any program I tested on them, even though I only tried programs that do not make any use of the OS or HW in any way , and only used BBC BASIC V commands for all interaction.

I think it may have been some unsupported and/or changed tokens, though I am not sure.

What use is a PRIVATE variable in a purely procedural language?

C has private (static) variables, and it's a procedural language. Without them you are forced to use globals for anything that is local in scope but needs to be preserved from one call to the next.

That is static, not private. Private usually refers to members of classes that are only accessible from within the class.

So I misunderstood the purpose. That is an advantage over LOCAL.

What use are interrupts in BBC BASIC?

Are you kidding? Most modern operating systems are event-driven so a programming language needs to have a mechanism for receiving those events asynchronously. The only alternative is an old-fashioned polling loop which is hopelessly inefficient and limiting.

That is not interrupts, that is call backs. And admittedly the support for such in BBC BASIC V is rather limited, and not very useful.

You can also handle interrupts and SWI's in code written in BBC BASIC by mixing in assembly (something missing from newer implementations)

What do you mean by "missing from newer implementations"? Brandy is the only version of BBC BASIC without an integral assembler, isn't it?

Out of context much?

Having an integral assembler is good for optimization, though it is even better when you can get the code running with low level access to the HW or system services that are not otherwise accessible.

I would like to see an example of BBC BASIC for Windows doing that

BBC BASIC for Windows can handle callbacks, if that is what you are referring to. There's a library for it, see the online documentation.

Richard.

I was referring to pushing assembled code into an area that it has direct access to HW or non-standard services, and is able to provide calls out to your BASIC program, as well as providing the same services to other running programs without relying on an external machine code library. This is where protected model OS's fail, and why the use of BBC BASIC V as an core part of RISC OS excels.

[mattmiller]

Could I suggest that a long discussion of relative merits is not started over BBC Basic on RiscOS vs BBC Basic on Raspbian

Let us just embrace both

[RichardRussell]

So I do not know where you get that only BB4W and BBCSDL support byte arrays, simply not true.

An array and a block of memory that you can access using indirection are quite different. For example with an array you have functions such as SUM() and MOD(), you can initialise all the elements in one fast step, you can perform arithmetic on all the elements in one statement, add two arrays together etc. You can't do any of those things with a memory block other than by coding a loop, which will be much slower.

Additional advantages of an array over a memory block include automatic index checking so that you don't accidentally stray outside of the array bounds, the ability to have a multi-dimensional array with the index calculated very quickly, and a function which returns the dimensions of the array without having to record them in variables.

If an array and a memory block were equivalent, there would be no reason to have integer arrays such as array%(1,2,3) because you could achieve the same functionality using a block of memory and 32-bit indirection. But in practice an array is often much more convenient and faster. The same applies to 8-bit indirection versus a byte array such as array&(2,3,4), when available.

Richard.

[mattmiller]

So that's a no then

[DavidS]

So that's a no then

It is a yes from me.

[rurwin]

What use are interrupts in BBC BASIC?

Are you kidding? Most modern operating systems are event-driven so a programming language needs to have a mechanism for receiving those events asynchronously. The only alternative is an old-fashioned polling loop which is hopelessly inefficient and limiting.

Those "interrupts" are called from an old-fashioned polling loop. It's just that newer GUI frameworks provide a call that does the polling loop for you.

What do you mean by "missing from newer implementations"? Brandy is the only version of BBC BASIC without an integral assembler, isn't it?

Totally off-topic, Microsoft has removed their integral assembler in the C compiler for 64-bit. It's causing us great problems. Intrinsics are no use and you can't call an external library if what you want to do is mess with the stack. (Well you can, but not easily.)

[jahboater]

Totally off-topic, Microsoft has removed their integral assembler in the C compiler for 64-bit. It's causing us great problems. Intrinsics are no use and you can't call an external library if what you want to do is mess with the stack. (Well you can, but not easily.)

Still off topic, but could you use MinGW instead? I don't know what state MSVC is in now, but a few years ago I changed to GCC (MinGW) partly because of Microsoft's stated intention never to support all of C99. GCC fully supports C99, C11, C++14 etc and has a very powerful inline assembly feature which is widely supported by other compilers.

[RichardRussell]

Those "interrupts" are called from an old-fashioned polling loop.

Are you talking specifically about RISC OS here? Windows supports genuine asynchronous interrupts (callbacks), for example from the Multimedia Timers. If a BASIC program is going to respond to such timer interrupts without needing a polling loop there needs to be a mechanism similar to the one I have incorporated in BBC BASIC for Windows and BBCSDL.

In implementation terms it's not at all complicated and could easily be retro-fitted to Acorn's (Sophie's) BASICs if needed. They periodically test the 'Escape' flag - after every statement is executed probably - and vector to the error handler if it is set. My BASICs do the same, but they also test an 'interrupt pending' flag (the callback is stalled in another thread) and if that is set they fake a GOSUB to the nominated handler (that's why the handler must terminate with a RETURN). So the interrupt 'latency' is the remaining duration of the statement currently being executed.

This scheme works well and has allowed me to do all sorts of things that would not otherwise have been possible.

Totally off-topic, Microsoft has removed their integral assembler in the C compiler for 64-bit. It's causing us great problems. Intrinsics are no use and you can't call an external library if what you want to do is mess with the stack.

I agree. The solution I have adopted is to continue to write 32-bit code (the kinds of programs I write would not benefit from 64-bit code anyway)!

Richard.

[DavidS]

Those "interrupts" are called from an old-fashioned polling loop.

Are you talking specifically about RISC OS here? Windows supports genuine asynchronous interrupts (callbacks), for example from the Multimedia Timers. If a BASIC program is going to respond to such timer interrupts without needing a polling loop there needs to be a mechanism similar to the one I have incorporated in BBC BASIC for Windows and BBCSDL.

In implementation terms it's not at all complicated and could easily be retro-fitted to Acorn's (Sophie's) BASICs if needed. They periodically test the 'Escape' flag - after every statement is executed probably - and vector to the error handler if it is set. My BASICs do the same, but they also test an 'interrupt pending' flag (the callback is stalled in another thread) and if that is set they fake a GOSUB to the nominated handler (that's why the handler must terminate with a RETURN). So the interrupt 'latency' is the remaining duration of the statement currently being executed.

This scheme works well and has allowed me to do all sorts of things that would not otherwise have been possible.

Again those are callbacks, done in a more general way than what BBC BASIC V supports. Though the reasonable way to implement something like that would be to extend the ON keyword, making a version of the form ON <event> PROCname([parameter,[parameter]...) | FNname([parameter,[parameter]...). As that is the way that callback events are done in BASIC where supported.

Calling asyncronous event callbacks "inturrupts" is more than a little confusing.

Also the Win32 API (which is still used in 64-Bit windows), defines that polling loops are still used for standard system events, though also provides a way to have the system do the polling loop for you with the newer NT implementations (starting with NT5.0 or NT5.3 if I am not mistaken [Windows 2000 or Windows XP]). Yes calbacks can be used for other things that are not part of the standard WIndows Poll loop, the same is true in RISC OS, and just about any other OS (even DOS).

In BBC BASIC V to handle callbacks, we have to use a small assembly language routine that is called by the callback, and updates some values to pass to BASIC through a polling loop, this is an unfortunate truth about the way things are, and one extension I have wanted to see fro BBC BASIC V (the one that is part of RISC OS, the original BBC BASIC V, as updated thus far).

Totally off-topic, Microsoft has removed their integral assembler in the C compiler for 64-bit. It's causing us great problems. Intrinsics are no use and you can't call an external library if what you want to do is mess with the stack.

I agree. The solution I have adopted is to continue to write 32-bit code (the kinds of programs I write would not benefit from 64-bit code anyway)!

Richard.

[RichardRussell]

Though the reasonable way to implement something like that would be to extend the ON keyword

Like BB4W's ON CLOSE, ON MOUSE, ON MOVE, ON SYS and ON TIME statements you mean?!

Richard.

[DavidS]

Though the reasonable way to implement something like that would be to extend the ON keyword

Like BB4W's ON CLOSE, ON MOUSE, ON MOVE, ON SYS and ON TIME statements you mean?!

Richard.

Yes like that, though no need for the ON CLOSE, ON MOUSE, ON MOVE, events, as these are part of the standard polling loop. Though for other things definitely like that. The problem is to make it less specific, so that it can be used for any callback, including user implemented system level code (such as an assembly routine that is pushed into the module area and acts as a module in RISC OS, or equilevent). Does BB4W support such things?

[RichardRussell]

Yes like that, though no need for the ON CLOSE, ON MOUSE, ON MOVE, events, as these are part of the standard polling loop.

It's true that you could probably make do with just ON TIME, because that could poll everything else (there would be no requirement for a 'polling loop' as such). But once the mechanism is in place, supporting other common events is a no-brainer.

Does BB4W support such things?

Yes, it's how the TIMERLIB library works. You can create as many timers as you like, each of which has an independent handler. This leverages another of the features of BB4W/BBCSDL: being able to pass a procedure name as a parameter:

Code: Select all

      timerid% = FN_ontimer(period%, PROCcallback, flags%)

Richard.

[DavidS]

Yes like that, though no need for the ON CLOSE, ON MOUSE, ON MOVE, events, as these are part of the standard polling loop.

It's true that you could probably make do with just ON TIME, because that could poll everything else (there would be no requirement for a 'polling loop' as such). But once the mechanism is in place, supporting other common events is a no-brainer.

Does BB4W support such things?

Yes, it's how the TIMERLIB library works. You can create as many timers as you like, each of which has an independent handler. This leverages another of the features of BB4W/BBCSDL: being able to pass a procedure name as a parameter:

Code: Select all

      timerid% = FN_ontimer(period%, PROCcallback, flags%)

Richard.

I mean creating callbacks for as many arbitrary sources, of anything that can call a callback, with out needing a specific lib, and then assigning them with an ON <event> statement.

Though I do admit there are a few things I would like to see in BBC BASIC V, the difficult is not breaking compatibility with identifiers that people are already using in RISC OS programs (the OS of BBC BASIC V).

[bensimmo]

Why not fire up Raspian or Windows if you have them and have a play and find out
If it's of no interest, then stick to the RISC versions.

[RichardRussell]

I mean creating callbacks for as many arbitrary sources, of anything that can call a callback, with out needing a specific lib, and then assigning them with an ON <event> statement.

You say "without needing a specific lib" but BB4W is highly dependent on libraries. Just as Sophie was, I am determined that BBC BASIC should remain 'lean and mean' and not be bloated with little-used features. Things that can go in a library, without performance suffering, should go in a library. The BB4W library which provides support for 'arbitrary' callbacks is, not surprisingly, the CALLBACK library.

the difficult is not breaking compatibility with identifiers that people are already using

Indeed I have always been very cautious about adding new keywords for this very reason; BB4W has only two keywords that ARM BASIC does not have: EXIT and PRIVATE. There is of course a risk that one or both of those might clash with a variable name in an existing program, but I couldn't see an acceptable way of repurposing existing keywords to provide the functionality.

Looking back 30 years or so, the addition of new keywords to BASIC V resulted in many compatibility issues of this kind, but Sophie obviously felt that the price was worth paying on that occasion.

Richard.

[ukscone]

Shouldn't be doing it over VNC but my main Pi2B is headless but quite impressed so far with my quick play with BBCBASIC on the Pi

p.s. a text only version usable over ssh would be nice to have one day

[DavidS]

I mean creating callbacks for as many arbitrary sources, of anything that can call a callback, with out needing a specific lib, and then assigning them with an ON <event> statement.

You say "without needing a specific lib" but BB4W is highly dependent on libraries. Just as Sophie was, I am determined that BBC BASIC should remain 'lean and mean' and not be bloated with little-used features. Things that can go in a library, without performance suffering, should go in a library. The BB4W library which provides support for 'arbitrary' callbacks is, not surprisingly, the CALLBACK library.

Point of keeping it lean and mean is understood. Though including a bunch of libraries is contrary to that goal, by a long run.

Sophies BBC BASIC V (ARM BASIC) relies only on what the OS already provides as standard, no extended libraries beyond that. Ok you can add your own libraries, though they are not required to implement the core language at all.

the difficult is not breaking compatibility with identifiers that people are already using

Indeed I have always been very cautious about adding new keywords for this very reason; BB4W has only two keywords that ARM BASIC does not have: EXIT and PRIVATE. There is of course a risk that one or both of those might clash with a variable name in an existing program, but I couldn't see an acceptable way of repurposing existing keywords to provide the functionality.

Looking back 30 years or so, the addition of new keywords to BASIC V resulted in many compatibility issues of this kind, but Sophie obviously felt that the price was worth paying on that occasion.

Richard.

Valid points. The difference now being the huge amount of software that has been developed in the last 30 years, and the particular identifiers PRIVATE and EXIT are fairly common in many of these, sometimes used in a huge number of places in programs in different ways, they are logical variable names for there intended purposes.

There is also some issue with the assembler, with the newer instruction mnemonics we have a specific OPT flag to enable these, as there is a high risk of a conflict with variable names, and the mnemonics are in the keyword name-space.

There is a lot of software that does not use anything other than the built in functions, statements, commands, and pseudo variables of BBC BASIC V, these should be easy to run on your BBC BASIC, assuming that you have been as diligent about keeping the tokens the same as the original. I will be giving yours a try, and hoping that you have been diligent about keeping the tokens the same as the original, as well as the memory map (relatively addressed that is). I also hope that it supports inline assembly in the same way as BBC BASIC V (even though most asm routines would have to be rewriten for use in Linux), I really like that syntax.

[DavidS]

Does your Linux version implement GPIO functionality in a way similar to how we do on RISC OS (I say similar, as I know it is not going to be using SWI calls with the SYS statement).

[RichardRussell]

Ok you can add your own libraries, though they are not required to implement the core language at all.

Of course libraries aren't required to implement the "core language" (by definition!) but BBC BASIC is missing many valuable features (some that are common in other BASICs) and the obvious way of supporting them is by supplying a set of standard libraries. This is no different from a language like C which is highly dependent on standard libraries for much of its functionality.

I suggest that we draw this discussion to a close because we are poles apart in our attitudes to BBC BASIC and I don't think there is any way the gap can be bridged.

Richard.