Introduction to BBC BASIC

[Soruk]

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!

Okay. Obviously I typoed it in my emulator as now (much to my surprise) I'm also getting 2 on my Master emulation and BASIC V on RPCEmu (RISC OS 3.71) are returning 2. However, I do get -4294967294 in BASIC VI. Two things can be drawn from this:
1) I absolutely suck at typing 10-digit numbers.
2) Matrix Brandy is actually closer to BASIC VI than BASIC V !!

[RichardRussell]

2) Matrix Brandy is actually closer to BASIC VI than BASIC V !!

My head is beginning to hurt, but what happens when you attempt assign the result to an integer variable:

Code: Select all

a% = -2147483647 - 2147483647

I presume that BASIC VI still sets a% to 2 in this case (if not it's less compatible with BASIC V than I imagined), whilst my BASICs report 'Number too big'. What does Matrix Brandy do?

[ejolson]

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.

I think it would be fine with 40-bit floats. The idea, but not the exact algorithm, was taken from old Fortran written before any kind of floating-point standards.

[Soruk]

2) Matrix Brandy is actually closer to BASIC VI than BASIC V !!

My head is beginning to hurt, but what happens when you attempt assign the result to an integer variable:

Code: Select all

a% = -2147483647 - 2147483647

I presume that BASIC VI still sets a% to 2 in this case (if not it's less compatible with BASIC V than I imagined), whilst my BASICs report 'Number too big'. What does Matrix Brandy do?

Matrix Brandy: Number is out of range
ARM BBC BASIC VI: Floating point exception: invalid operation

As (with @%=10) a PRINT of the sum gives -4294967294, I suspect it correctly calculated it, then tried to stuff that into a 32-bit integer variable which understandably fails.

[Steve Drain]

I couldn't write programs without structures, private variables, indirect function calls, long strings and all the other language enhancements that my versions have.

I think both Richard and David are aware of my Basalt (BASIC Alternative keywords) module with all those extensions and more for ARM BASIC V. It does not implement them in an identical fashion to Richard's, but they have been available to ARM users for a very long time. It is also possible to implement some of them in libraries or exploiting features of ARM BASIC. Richard and I have also exchanged ideas on very long strings, each producing a library for our own versions.

[John_Spikowski]

FWIW:

Code: Select all

PRINT FORMAT("%.f\n",-2147483647 - 2147483647)


[email protected]:~/sbrpi/bbc $ scriba bbcint.sb
-4294967294

[DavidS]

I couldn't write programs without structures, private variables, indirect function calls, long strings and all the other language enhancements that my versions have.

I think both Richard and David are aware of my Basalt (BASIC Alternative keywords) module with all those extensions and more for ARM BASIC V. It does not implement them in an identical fashion to Richard's, but they have been available to ARM users for a very long time. It is also possible to implement some of them in libraries or exploiting features of ARM BASIC. Richard and I have also exchanged ideas on very long strings, each producing a library for our own versions.

Yes and it is an extension I often use. Though still would like to see some of your features make it into the actual ROMModule.

Good to see you here.

[RichardRussell]

Richard and I have also exchanged ideas on very long strings, each producing a library for our own versions.

My huge string library was never very satisfactory, and I eventually abandoned it in favour of natively supporting arbitrary-length strings (limited only by available memory) in version 6 of BBC BASIC for Windows and all editions of BBC BASIC for SDL 2.0. Once you have that capability it changes the way you approach certain problems. For example if I want to search for something in a file, I'll load the entire file into a string (assuming it will fit in memory) and use INSTR!

Code: Select all

      string$ = GET$#file% BY EXT#file%

(the BY and TO qualifiers for GET$# are another BB4W/BBCSDL extension).

Brandy at least increased the maximum string length from 255 to 65535 which is useful; I've never really understood why Sophie didn't do the same in ARM BASIC given the likelihood of much more memory being available compared with a BBC Micro. But it's only when you can load tens of megabytes or more into a single string that the way you think about them really changes.

[John_Spikowski]

Are there any array size or indecie limitations with BBC BASIC / Brandy?

I wouldn't use a BASIC that had a 64KB string length limitation.

[DavidS]

Are there any array size or indecie limitations with BBC BASIC / Brandy?

I wouldn't use a BASIC that had a 64KB string length limitation.

No limits for BBC BASIC V/VI. Only limitted by available memory. I guess technically you could not exceed 2GB arrays, though that is not much of a limit.

[Soruk]

Are there any array size or indecie limitations with BBC BASIC / Brandy?

I wouldn't use a BASIC that had a 64KB string length limitation.

No limits for BBC BASIC V/VI. Only limitted by available memory. I guess technically you could not exceed 2GB arrays, though that is not much of a limit.

Similarly in Matrix Brandy, array size is only limited to available memory up to 2GB, though noting that the memory available is specified either by the -s option or by a parameter to the NEW command.

[RichardRussell]

I wouldn't use a BASIC that had a 64KB string length limitation.

Early versions of BBC BASIC, including ARM BASIC VI which is the latest and 'best' from the Acorn stable, have a maximum string length of 255 bytes!! Can you believe it? And whilst there are various workarounds, such as using 'indirection' (a fancy name for PEEK and POKE when it comes to it) to manipulate characters in memory, they are thoroughly unsatisfactory. BASIC's string handling capabilities (including automatic memory management) are one of the key stengths of the language, something that even C does not have as standard. Supporting arbitrary length strings is probably the single most important extension I have provided.

Since BBC BASIC arrays have never had a similar size limitation it's quite hard to understand the mindset of Acorn/Sophie in restricting strings in this way, even when ARM BASIC was developed for a true 32-bit machine with potentially megabytes of memory. Although (tokenised) BBC BASIC programs lines are themselves similarly restricted in length, once tokens are expanded they can easily exceed the 255 characters of a string, so in those days the language couldn't necessarily even store a line of its own code as plain text in a string!

It's noteworthy that Brandy, which normally strives to reproduce every nuance of Acorn's BASICs even if you can argue it's a bug, balked at retaining the 255-byte string limitation and increased it to 64K.

[Steve Drain]

Richard and I have also exchanged ideas on very long strings, each producing a library for our own versions.

My huge string library was never very satisfactory, and I eventually abandoned it in favour of natively supporting arbitrary-length strings (limited only by available memory) in version 6 of BBC BASIC for Windows and all editions of BBC BASIC for SDL 2.0. Once you have that capability it changes the way you approach certain problems. For example if I want to search for something in a file, I'll load the entire file into a string (assuming it will fit in memory) and use INSTR!

Although my library exists, I too incorporated the ideas into Basalt, so this supports strings of unlimited length in addition to the existing 255-byte strings. These string variables are the same as normal but enclosed in parentheses:(string$). You can use INSTR on them as well!

Code: Select all

      string$ = GET$#file% BY EXT#file%

(the BY and TO qualifiers for GET$# are another BB4W/BBCSDL extension).

A interesing extension.

Brandy at least increased the maximum string length from 255 to 65535 which is useful; I've never really understood why Sophie didn't do the same in ARM BASIC given the likelihood of much more memory being available compared with a BBC Micro. But it's only when you can load tens of megabytes or more into a single string that the way you think about them really changes.

Shades of BETABasic for the Spectrum, where MEMORY$ represented the whole computer memory and could be searched and sliced.

[Steve Drain]

it's quite hard to understand the mindset of Acorn/Sophie in restricting strings in this way, even when ARM BASIC was developed for a true 32-bit machine with potentially megabytes of memory.

The 255 byte limit is very constraining, but I think I can see how it has survived. The original size matched the available memory in the first RISC OS machines. The method of handling strings with a 'striing information block' (SIB) with a single byte for the length rather baked that into the code. Sophie's assembly source itself is rather inpenetrable and teasing out all the implications of changing the SIB has probably daunted many who might have made the change. For most purposes 255 bytes are enough and this also corresponds some OS limitations that have yet to be resolved. A new implementation such as Brandy makes the change relatively simple.

[Heater]

@RichardRussell,

Early versions of BBC BASIC, including ARM BASIC VI which is the latest and 'best' from the Acorn stable, have a maximum string length of 255 bytes!! Can you believe it?

Why would anyone not believe it. It's a natural thing to do:

When implementing strings what can one do? Have a pointer to memory and a length stored with the string. Like Pascal. Or have a pointer to memory and put a null byte at the end. Like C. Have two pointers, one to the start of the string and one to the end. Something else?

Given the tiny amounts of memory the machines C was developed on, and the desire for strings of any length it makes sense to do what C did, don't store the length and put a null on the end.

Given the tiny amounts of memory the machines BASIC and Pascal were developed on, it makes sense to restrict the size of the length field, wherever you store it, to a single byte.

I suspect the Pascal/BASIC guys were more concerned with numerical calculation than text processing so it makes sense that they use a length field for strings. Only one byte, to save memory. It has algorithmic advantages.

The C guys needed to be able to write compilers and such text processing tools, so it makes sense they allowed for long strings.

@Steve Drain

The 255 byte limit is very constraining, but I think I can see how it has survived. The original size matched the available memory in the first RISC OS machines.

I don't follow. I'm pretty sure even the first RISC OS machines had a lot more than 256 bytes of RAM!

[jahboater]

Given the tiny amounts of memory the machines C was developed on, and the desire for strings of any length it makes sense to do what C did, don't store the length and put a null on the end.

Which takes one byte regardless of the length. Also the strings value in an expression is the address of the first byte - exactly the same as any other array. The scan for the NUL is pretty fast (one "repne scasb" instruction on Intel).

[ejolson]

Given the tiny amounts of memory the machines C was developed on, and the desire for strings of any length it makes sense to do what C did, don't store the length and put a null on the end.

Which takes one byte regardless of the length. Also the strings value in an expression is the address of the first byte - exactly the same as any other array. The scan for the NUL is pretty fast (one "repne scasb" instruction on Intel).

The obvious drawback is not being able to store the NULL character nor knowing the length of the string before counting the characters. On the other hand, since C has structures, it doesn't take more than a minute to write something like

typedef { int n; char *p; } string;

and you have something with a built-in letter count. Of course there is still a bit of work to do if you want automatic garbage collection. Around here we pay for the garbage collection by the size of the bin.

[jahboater]

The obvious drawback is not being able to store the NULL character

"abc\0def" is valid of course - if you know what you are doing and have some strange reason for it!

Its often handy to be be able to quickly truncate a string with: str[n] = '\0';

[RichardRussell]

Why would anyone not believe it. It's a natural thing to do:

There's nothing "natural" about a a maximum string length of 255 bytes, in my opinion! It's an entirely artificial limit.

Or have a pointer to memory and put a null byte at the end.

That's not really an option for two reasons. Firstly it's incredibly useful for strings to be able to contain any characters at all (including NUL); I have previously discussed how BBC BASIC uses the 'VDU stream' to represent graphics operations so you can store complete graphics objects in a string in a similar way to a Windows metafile. Such VDU sequences very commonly include NULs. Secondly you cannot store UTF-16 (or UCS-2) encoded Unicode in a string which is terminated by a single NUL character (you can use UTF-8 instead but that's not always convenient, especially in Windows).

Given the tiny amounts of memory the machines BASIC and Pascal were developed on, it makes sense to restrict the size of the length field, wherever you store it, to a single byte.

Quite. I'm not arguing that the 255-byte limit was inappropriate for the BBC Micro, which could have as little as 5K memory available (and never more than 30K). But when ARM BASIC was developed all sorts of valuable extensions were added: WHILE loops, CASE statements, multi-line IF...ENDIF blocks, array arithmetic etc. This was a major revision of the BBC BASIC specification to bring it up to a more modern standard (for the day, i.e. around 1985) and make it more suitable for running on a 32-bit machine. It's at that point that I think the string length limit should have been increased.

[RichardRussell]

The method of handling strings with a 'striing information block' (SIB) with a single byte for the length rather baked that into the code.

Before I supported arbitrary (32-bit) length strings, I extended the maximum length from 255 to 65535 characters without making the SIB any bigger. The old SIB had one byte holding the current length of the string and another byte holding the maximum length of the string. The change I made was for the maximum length to be deducible from the current length using a simple algorithm:

Code: Select all

 maximum_length = 2^(INT(LOG2(current_length)) + 1) - 1 

(that may not look simple but it's a single instruction in the modern x86 and ARM instruction sets).

Once the maximum length doesn't need to be stored explicitly the current length can use both bytes! This strategy was easy and safe to implement, and served me well until I moved to a 32-bit length field in BB4W version 6 and BBCSDL.

[DavidS]

While there are definitely advantages of having native long strings without using indirection, as well as structured datatypes, and inderection of PROC/FN calls in interpreted, we can thank Steve Drain for Basalt which gives us these things and more.

I had not mentioned Basalt before Steve Drain came and brougth it up, as I am not sure how many of those new to RISC OS may be aware of it.

I would still like to see the Basalt extensions become part of BASIC V and VI. I believe this to be possible, as extensions to the language in the way they are in Basalt, without modifying the default behaviours at all. And I also believe that having Basalt built into Sophie Wilsons module would make these extensions faster than they already are.

I think that Steve Drain likely knows more about Sophie Wilsons BBC BASIC V/VI than anyone other than Sophie Wilson. At least he has done more to help us in doing more with ARM BASIC than anyone else I know of.

[RichardRussell]

I would still like to see the Basalt extensions become part of BASIC V and VI.

If that were ever to happen it would make the rift between the Wilson and Russell strands of BBC BASIC unbreachable, because whatever the merits of Steve's extensions, and of mine, they are fundamentally incompatible (not even similar, in most cases). Not surprisingly, I would rather support the moves to incorporate my extensions in ARM BASIC, as exemplified by Jonathan Harston's BASICPlus. Sadly development of that stalled several years ago, despite Jonathan having already implemented several of my extensions, and as his modifications were made to a version of ARM BASIC which has long been superseded it might be difficult to transfer them to a newer version.

[Heater]

RichardRussell,

There's nothing "natural" about a a maximum string length of 255 bytes, in my opinion! It's an entirely artificial limit.

Yes, it's as unnatural as limiting integer range to whatever fits into 16, 32, 64... bits.

I meant "natural" as in an obvious solution to implementing strings on such limited machines. Especially if text processing is not really your emphasis. It comes so naturally that Pascal did it as well.

That's not really an option for two reasons. Firstly it's incredibly useful for strings to be able to contain any characters at all (including NUL); I have previously discussed how BBC BASIC uses the 'VDU stream'

It certainly can be. But then we are not dealing with "strings" as intended for printable text but rather byte arrays. Using strings for byte arrays is some kind of kluge.

Secondly you cannot store UTF-16 (or UCS-2) encoded Unicode in a string which is terminated by a single NUL character

Why would you want to store 16 bit items into a type intended for ASCII character strings? Obviously if your elements are 16 bits you would make your end sentinel 16 bits as well.

(you can use UTF-8 instead but that's not always convenient,...

UTF-8 is a brilliant hack to encode Unicode into character strings. Yes, it's not always convenient, for a start it impossible to know how many characters long such a string is without parsing it all.

...especially in Windows).

Meh...Who cares.

[DavidS]

I would still like to see the Basalt extensions become part of BASIC V and VI.

If that were ever to happen it would make the rift between the Wilson and Russell strands of BBC BASIC unbreachable, because whatever the merits of Steve's extensions, and of mine, they are fundamentally incompatible (not even similar, in most cases). Not surprisingly, I would rather support the moves to incorporate my extensions in ARM BASIC, as exemplified by Jonathan Harston's BASICPlus. Sadly development of that stalled several years ago, despite Jonathan having already implemented several of my extensions, and as his modifications were made to a version of ARM BASIC which has long been superseded it might be difficult to transfer them to a newer version.

I think someone could probably write a program to convert source that uses the extensions between your BBC BASIC and Steves extensions if they so wished. I do not think it would be to difficult.

[RichardRussell]

Using strings for byte arrays is some kind of kluge

Except that strings are supported by a rich set of built-in functions, such as INSTR() for searching, and there are generally no similar functions that operate on byte arrays. So from a performance and convenience standpoint strings are often a better choice even when what you are storing in them isn't 'text'. Note that (my) BBC BASIC has byte arrays too so you have the choice.

Why would you want to store 16 bit items into a type intended for ASCII character strings?

Because it's the only kind of string BBC BASIC has! You can't 'magic up' a wide-character string for storing your UTF-16 text when the language you are using doesn't have such a data type, you have to use what you're given. Because BBC BASIC's strings (indeed most BASICs' strings) can hold anything, they can hold UTF-16 data.

for a start it impossible to know how many characters long such a string is without parsing it all.

Just as it's impossible to know how many characters are in a NUL-terminated string without searching the entire string from the beginning! Anyway I supply a library - utf8lib.bbc - which includes functions for operating on UTF-8 strings, including one to return the length in characters.

Meh...Who cares.

I care. Windows is by far the most important target platform for BBC BASIC, since it's by far the most popular desktop operating system (87.6% share according to WIkipedia, with MacOS running at 9.7% and Linux a measly 2.1%).