Introduction to BBC BASIC

[Soruk]

Don't fall into the trap of equating 'integer variable' (which is a particular data type) with 'integer' (which is a mathematical concept meaning 'whole number').

Edit: Just to prove the point (not that I was in any doubt) you can run this on the original BBC Micro:

Code: Select all

@%=10
FOR A = -4294967296 TO -4294967280
  PRINT A
NEXT

You're absolutely right, I was indeed falling into that trap. That code snippet ran perfectly in BeebEm, RPCEmu and Matrix Brandy.

[Soruk]

Wow, my humble Fibo challenge seems to have been doing a great job of shaking out the bugs in various language run-times. I hope they are all getting reported and fixed so that this has not been entirely a waste of time.

As the maintainer of Matrix Brandy, I do look out for stuff like this to test the robustness of the interpreter! In this case I have scruss to thank for raising the github ticket on this (and alerting me to this thead!). So, at least from where I'm sitting, not a waste of time at all.

[DavidS]

That norm is only for BASIC implementations that store integers primarily in floating point (like most older MS-BASIC implimentations).

I have literally no idea what that means. The way a standard function like INT() behaves obviously should not, and must not, depend on implementation details. In BASIC INT() truncates towards minus infinity; do you know of any non-conforming BASICs except Liberty BASIC?

I was speaking about the part of storing the resulting Integer in a floating point value. Most BASIC implimentations will store the resulting integer result as an integer.

In All BASIC's that I have ever used INT rounds towards negitive infinity (floors).

[DavidS]

It is interesting how often the differences in how to implement LOG( and LN( in BASIC come up. I remember a few computers that had BASIC in ROM that the documentation whent to great length as to how MS had it wrong and they had it correct.

I forget what it is for Dartmouth BASIC (the basis of ANSI BASIC, and the original), though I have a feeling that it dissagrees with MS-BASIC.

Just because many BASIC interpreters of the late 1970's and early 1980's were written by MS does not mrean that all were. Remember Atari BASIC on the 6502 based Atari Computers? There are many other examples, though I have always felt the way BBC BASIC does it is the best, and at least BBC BASIC itself is kind of an accepted standard (even if some implementations streach the rules a little).

[DavidS]

if it supports up to 53-bit integers (as ARM BASIC 6 and Brandy do)

Unless I'm doing something wrong, they don't.

You are trying to load the number into an integer-type variable a%. Obviously that is going to fail, because integer variables can hold only 32-bit integers. But ordinary (non % suffix) variables can hold integers up to 53-bits; the size of integer that can be contained in a 'floating point' variable depends on the number of bits in the mantissa.

While it is true that a floating point value can hold a integral value greater than 2^32-1, that is still being stored as a floating point value.

And you are the first I have ever heard call a floating point variable an ordinary variable, most seem to consider the integer variables the ordinary type.

Even in 8-bit BBC BASICs and ARM BASIC 5 an ordinary variable like a can contain a wider range of integers than an integer variable like a% can, but the increase is only a factor of two. The range of integers that can be held in a% is -2147483648 to +2147483647 whereas the range of integers that can be held in a is -4294967296 to +4294967296!

So BASIC V and up allow better positive range of variables than the older BBC BASICs? In BASIC V an integer variable may be treated as unsigned, thus allowing for values up to 2^32-1 (4294967295). Put another way if being used as unsigned an integer variable n has the range of 0 <= n <= 4294967295.

Don't fall into the trap of equating 'integer variable' (which is a particular data type) with 'integer' (which is a mathematical concept meaning 'whole number').

And hence the reason that the manuals for BBC BASIC are very clear about returning an integer type (with all its limits) from certain functions like INT(. Would it be wrong in any language to specify the return type of a library function (which is what INT( is to BASIC)? And in the case of BBC BASIC it is defined as returning an integer type (the same type as supported by the integer variables).

[DavidS]

Also remember that in BBC BASIC integer type variables do NOT need to have a % postfix. While most do it that way you can create integer variables that do not, for example:


Ok the manual does not match the behaviour on testing.

According to the documentation the variables in this example should be of integer type, though the result shows otherwise (it works):

Code: Select all

ON ERROR PRINT "LINE : " + STR$(ERL) + " ERROR : " + REPORT$ : E

DIM buf% 100

P% = buf%
[OPT 0
.vara
.varb
.varc
  EQUD 0
]
REM the following will error do to attempting to assign a
REM a non integral real number to an integer type variable.
vara=3: varb = 10 : varc = varb / vara
PRINT varc
END

It actually prints 3.333333333, not what I expected, and not what the manual indicates. By the documentation vara, varb, varc should be integer type variables.

[RichardRussell]

While it is true that a floating point value can hold a integral value greater than 2^32-1, that is still being stored as a floating point value.

You seem to like to concentrate on implementation detail, when that shouldn't matter to the programmer. Regardless of how it's stored, it's an integer! But in any case what you state there is not true of my BASICs: going right back to BBC BASIC (Z80), when an integer value is stored in a suffixless variable like 'a' it isn't stored in floating point format! Strictly such variables are not 'floats' but 'variants' in my versions, and you will find them referred to as such in the documentation.

And you are the first I have ever heard call a floating point variable an ordinary variable, most seem to consider the integer variables the ordinary type.

BASIC traditionally has only two variable types, numeric and string. 'Integer variables', of the sort that BBC BASIC has, are a relatively new-fangled extension and some BASICs even today don't have them (for example Liberty BASIC). So I feel very strongly that the 'suffixless' numeric variable is the 'normal' type. In all early versions of BBC BASIC there wasn't even any saving in memory by using a (scalar) integer variable: the saving in one byte of storage (32-bits rather than 40) was exactly matched by the additional '%' suffix character! Of course there is a memory saving with arrays.

So BASIC V and up allow better positive range of variables than the older BBC BASICs?

No, BASIC 5 is the same as earlier versions; BASIC 6 (BASIC64) was the first to increase the range.

In BASIC V an integer variable may be treated as unsigned, thus allowing for values up to 2^32-1 (4294967295).

Where do you get that idea from? Integer variables are signed, just as they are in all other versions of BBC BASIC. An unsigned integer variable would need to have a different suffix character. You appear to have 'invented' a feature that it has never had!

And hence the reason that the manuals for BBC BASIC are very clear about returning an integer type (with all its limits) from certain functions like INT(

I know they're "clear", but it is no less silly. Sophie didn't often get things wrong, but this is one occasion when she did. You didn't answer my supplementary question so I will ask it again: since truncating a value like 2^50+0.5 to an integer is clearly a perfectly sensible thing to want to do, how would you code that in ARM BASIC 6? In BBC BASIC for Windows and BBC BASIC for SDL 2.0 you simply use the INT function.

[ejolson]

I forget what it is for Dartmouth BASIC (the basis of ANSI BASIC, and the original), though I have a feeling that it dissagrees with MS-BASIC.

In Dartmouth Basic LOG refers to the natural logarithm. In most mathematics texts beyond Calculus log also refers to natural logarithm. Since

log10(x)=log(x)/log(10)

no matter what base logarithm log stands for, there is not much advantage from a programming point of view to having base-10 logarithms built into the language. In fact, doing so removes important low-hanging fruit such as

10 DEF FNL(X)=LOG(X)/LOG(10)

that can be useful to get people started writing programs.

Admittedly, when teaching at very low knowledge levels, it may be useful to have a built-in function which represents the base-10 logarithms learned at younger ages. Luckily the developers didn't follow the same strategy with the circular functions. Imagine how much more mayhem could be caused if the BBC Basic versions of SIN and COS took an argument expressed in degrees while CNR and CSR were introduced for the radian-based functions.

While it is convenient on a calculator to have buttons for base-10 logarithms as well as sine and cosine using degrees, computers are different--namely programmable. In my opinion, the inconvenience of changing the meaning of LOG between Basic versions likely outweighed the advantages. At the same time, long gone are the days when Basic programs were included in science textbooks.

Although it is interesting to discuss what factors may have contributed to the demise of the first age of personal computing, the only thing that can be changed now is the future.

[RichardRussell]

By the documentation vara, varb, varc should be integer type variables.

What documentation? BBC BASIC is an explicitly-typed language; the only way the interpreter knows the type of a variable is by its suffix character(s). In my versions there are more types than there are in Acorn's:

No suffix: variant (64-bit integer or 80-bit float)
%: 32-bit signed integer
%%: 64-bit signed integer
&: 8-bit unsigned integer
#: 64-bit float ('double')
$: string

[DavidS]

Where do you get that idea from? Integer variables are signed, just as they are in all other versions of BBC BASIC. An unsigned integer variable would need to have a different suffix character. You appear to have 'invented' a feature that it has never had!

From the manuals, and some programs that use Integer variables as unsigned. It is still true that in many cases it is faster to use integer math on the CPU than floating point on the FPU.

The type itself is neither signed or unsigned, it is how it is operated on that makes the difference. It is even possible to print it as unsigned value (I forget how when working with base 10 number systems, though for hex it is easy ~).

Every BASIC I have ever used (down to MS-8KB BASIC) has an integer type, the old MS versions do all there calculations in floating point (I think they like slow). Liberty BASIC sounds messed up.

Not sure about Dartmouth BASIC, though it would stand to reason that there were integer types.

It is not so much about the storage space as it is about the way the data is processed (speed) as well as how to access it.

On leaving out %
Variables that are used as labels in an assembler listing are defined to be integer type regardless of there suffix, this do to the fact that they are used as pointers. And that is how it works in some earlier versions of BASIC V (tested in past)

[RichardRussell]

In my opinion, the inconvenience of changing the meaning of LOG between Basic versions likely outweighed the advantages.

I don't know how old you are, but if you are as old as me you could have argued the point in 1981! It's evident that on the balance of the evidence and advice the BBC received then, a different conclusion was drawn.

Imagine how much more mayhem could be caused if the BBC Basic versions of SIN and COS took an argument expressed in degrees

BBC BASIC does have the DEG and RAD functions, and because the language syntax often allows you to create compound keywords by concatenation it follows that COSRAD() and SINRAD() functions effectively exist (as do DEGASN, DEGACS and DEGATN).

[DavidS]

@RichardRussell:
For your implimentation such details do not effect the result. You have up to 64-bits of presision in either integer or floating point variables. I would hope that you do your integer stuff in the CPU, though the results will still be the same for your version of BBC BASIC (because you have 64-bit integer variables).

[RichardRussell]

From the manuals, and some programs that use Integer variables as unsigned.

Can you quote the relevant section of the manual or list one such program?

The type itself is neither signed or unsigned, it is how it is operated on that makes the difference.

Nope, not true. Integer variables in BBC BASIC are signed.

It is even possible to print it as unsigned value (I forget how when working with base 10 number systems, though for hex it is easy

Also not true. Hexadecimal can represent either signed or unsigned numbers of course (as can binary) but BBC BASIC has no built-in means of printing a negative integer as an unsigned decimal number. You can write a function to do it if you like.

Liberty BASIC sounds messed up.

It is! I have already given the example of the non-standard INT function, and there are other non-standard features (e.g. AND doesn't have priority over OR in expressions). But in respect of only having a variant (suffixless) numeric variable type it is quite standard.

Not sure about Dartmouth BASIC, though it would stand to reason that there were integer types.

Why "stand to reason"? Numbers are numbers and if there's a performance advantage in internally representing integers in a different format from non-integers it's something the interpreter can reasonably be expected to do itself rather than the programmer having to.

Variables that are used as labels in an assembler listing are defined to be integer type regardless of there suffix

Nope, not true. You presented the evidence that it's not true in an earlier post, yet you still assert it.

Here's something to mull over. Given how you think BBC BASIC works it will probably cause your head to explode! Results of the listed code running in BBC BASIC for SDL 2.0 on Windows:

Code: Select all

      TIME = 0 : FOR a% = 1 TO 10000000 : NEXT : PRINT TIME
      TIME = 0 : FOR a = 1 TO 10000000 : NEXT : PRINT TIME
      TIME = 0 : FOR a = 1.0 TO 10000000.0 : NEXT : PRINT TIME

Giving:

Code: Select all

        19
        19
        46

So using an 'integer' variable conferred no speed advantage at all, but adding '.0' to the end of the constants drastically reduced the speed. This is how variants should behave.

[ZXDunny]

Not sure about Dartmouth BASIC, though it would stand to reason that there were integer types.

All numeric variables in Dartmouth are floating-point representations. Dartmouth has nothing to say about the size, however. There are no suffixes to denote type other than "$" which indicates a string variable.

[DavidS]

From the manuals, and some programs that use Integer variables as unsigned.

Can you quote the relevant section of the manual or list one such program?

The type itself is neither signed or unsigned, it is how it is operated on that makes the difference.

Nope, not true. Integer variables in BBC BASIC are signed.

It is even possible to print it as unsigned value (I forget how when working with base 10 number systems, though for hex it is easy

Also not true. Hexadecimal can represent either signed or unsigned numbers of course (as can binary) but BBC BASIC has no built-in means of printing a negative integer as an unsigned decimal number. You can write a function to do it if you like.

Really? Run the statement PRINT ~x% where x% contains a value having the high bit set (will display an unsigned hexadecimal value).

Variables that are used as labels in an assembler listing are defined to be integer type regardless of there suffix

Nope, not true. You presented the evidence that it's not true in an earlier post, yet you still assert it.

I do not assert it anylonger, I admit that the way it works now is different than what I have always expected. that is the point of the statements I just made.

Here's something to mull over. Given how you think BBC BASIC works it will probably cause your head to explode! Results of the listed code running in BBC BASIC for SDL 2.0 running on Windows:

Code: Select all

      TIME = 0 : FOR a% = 1 TO 10000000 : NEXT : PRINT TIME
      TIME = 0 : FOR a = 1 TO 10000000 : NEXT : PRINT TIME
      TIME = 0 : FOR a = 1.0 TO 10000000.0 : NEXT : PRINT TIME

Giving:

Code: Select all

        19
        19
        46

So using an 'integer' variable conferred no speed advantage at all, but adding '.0' to the end of the constants drastically reduced the speed. This is how variants should behave.

In that case I would have to assume that you are using Floating point math on your integers. Because on a RPi 1B+ running at 1000MHz (all other clocks stock) the same program gives:

Code: Select all

*BASICVFP
ARM BBC BASIC VI (VFP) (C) Acorn 1989

Starting with 649316 bytes free

>TEXTLOAD "T2"
Program renumbered
>SAVE "TT2"
>LIST
   10      TIME = 0 : FOR a% = 1 TO 10000000 : NEXT : PRINT TIME
   11      TIME = 0 : FOR a = 1 TO 10000000 : NEXT : PRINT TIME
   12      TIME = 0 : FOR a = 1.0 TO 10000000.0 : NEXT : PRINT TIME
>RUN
        62
        94
        94
>

And that is even using VFP .

Note that the integer result is the fastest. I directly saved the code you posted, loaded it into BASICVFP, saved a tokenized copy, then listed and ran the loaded copy (as you can see).

[RichardRussell]

Really? Run the statement PRINT ~x% where x% contains a value having the high bit set (will display an unsigned hexadecimal value).

Hexadecimal is neither signed nor unsigned. It is simply a convenient representation of a binary number (a sequence of zeroes and ones) in a shorter, more readable form.

In that case I would have to assume that you are using Floating point math on your integers.

It would be a totally illogical assumption, based on the evidence. The converse is of course the case: integers use integer arithmetic (typically CPU instructions) and floats use floating-point arithmetic (usually FPU instructions).

Because on a RPi 1B+ running at 1000MHz (all other clocks stock) the same program gives

Your results and mine are consistent with how we know Acorn's BASICs work (suffixless variables are floats) and how my BASICs work (suffixless variables are variants).

[DavidS]

Really? Run the statement PRINT ~x% where x% contains a value having the high bit set (will display an unsigned hexadecimal value).

Hexadecimal is neither signed nor unsigned. It is simply a convenient representation of a binary number (a sequence of zeroes and ones) in a shorter, more readable form.

And yet there are some languages that will display negitive hexadecimal numbers (eg range of -&7FFFFFFF through positive).

Remember hexadecimal is just a number base (base 16), just as decimal is just a number base (base 10). The choise of displaying either as signed or unsigned is no different.

In that case I would have to assume that you are using Floating point math on your integers.

It would be a totally illogical assumption, based on the evidence. The converse is of course the case: integers use integer arithmetic (typically CPU instructions) and floats use floating-point arithmetic (usually FPU instructions).

In that case I am surprised that a computer powerful enough to run a modern windows is that slow (about 5 times faster than a RPi 1B+ in this case), at least for runing BBC BASIC interpreted (compiled would be differnt [is there a compiler for BBC BASIC for SDL]).

Though yet one of your float variables shows the same performance as integer? Do you promote it to integer for cases where there is an advantage in so doing?

Because on a RPi 1B+ running at 1000MHz (all other clocks stock) the same program gives

Your results and mine are consistent with how we know Acorn's BASICs work (suffixless variables are floats) and how my BASICs work (suffixless variables are variants).

[Heater]

DavidS,

The type itself is neither signed or unsigned, it is how it is operated on that makes the difference.

What?!

The signed or signedness of numbers is one of the many properties of numbers that types in high level programming languages define.

I'm having a hard time imagining a number that is neither signed or unsigned. I suspect you are referring to the bunch of bits used to store that number in memory. Which is not even a number. It's a bunch of bits in memory.

Please read https://en.wikipedia.org/wiki/Data_type before discussing further.

[DavidS]

DavidS,

The type itself is neither signed or unsigned, it is how it is operated on that makes the difference.

What?!

The signed or signedness of numbers is one of the many properties of numbers that types in high level programming languages define.

I'm having a hard time imagining a number that is neither signed or unsigned. I suspect you are referring to the bunch of bits used to store that number in memory. Which is not even a number. It's a bunch of bits in memory.

Please read https://en.wikipedia.org/wiki/Data_type before discussing further.

While I see your point, the value is just a value stored somewhere (register, cache, memory). The operations on the integer value are where the difference is. If you are treating the 32-bit value as unsigned in the operations then it is being used as unsigned, if you are treating it as signed, then it is being used as signed.

Most languages are more specific about using the data type to determine how operations affect the value (where sign makes a difference). The only things we have difficulty with are division and multiplication (both of which are explicitly signed in BBC BASIC).

Going on with thread releated other.
I still think that the more amazing thing is how slow that simple test runs on a Windows PC. Especially with how many people on these forums brag about how much faster a Windows PC is than a Raspberry Pi (up to the 3B), and how the RPi 4B is marketed as Very Low End Desktop PC level. Knowing from previous tests that the 3B on one core is at least 5 to 7 times faster on most things (including BBC BASIC), that puts the performance of that test in BBC BASIC for SDL on a Windows PC as just a little slower than it would be on an RPi 3B+ in BBC BASIC VI (VFP). I think this actually makes for the first of the tests comparing BBC BASIC to BBC BASIC .

Maybe it is time to start a thread to compare these 4 versions of BBC BASIC for performance (BBC BASIC for SDL, Matrix Brandy BASIC, BBC BASIC V, AND BBC BASIC VI (VFP)). I think this could be more interesting than a thread to compare different interpreted languages. We already have two tests to get us started (the ridiculous huge value Fibo, and the simple loop test) that now run on all of these versions of BBC BASIC. Will need to write a few more tests (and be careful that they will run on all 4 implementations), some of that is done already (in preparing for something different), though more to do.

If I do such a thread it will include test code from the first post, so may take a few days. I will include the kind of messed old style BASIC version of the Huge Fibo that runs on all 4 target versions of BBC BASIC. Though there need to be a reasonable number of tests.

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

[John_Spikowski]

Who cares which retro BASIC is fastest? Let's just be thankful there are those with enough spare time on their hands to keep them running.

[RichardRussell]

In that case I am surprised that a computer powerful enough to run a modern windows is that slow (about 5 times faster than a RPi 1B+ in this case)

Sophie put a lot of effort into optimising the NEXT statement, and that was made easier as a result of there being only two numeric variable types that can be used as the control variable. In my modern BASICs there are five different types of numeric variable, all of which can be the control variable of a FOR ... NEXT loop, so the code I've used is more generic (and hence slower). Only in the case of an empty loop (or a loop with a very short 'body') does the speed of NEXT dominate.

is there a compiler for BBC BASIC for SDL

As you should be aware, BBC BASIC cannot be compiled (there are several language features, not least the EVAL function, that make it impractical). My BASICs support compressing ('crunching') the code and the replacement of variables etc. with inline pointers, but not true 'compilation'.

Though yet one of your float variables shows the same performance as integer?

Do you not read my posts? I explained that in my BASICs suffixless variables are variants, not floats.

[DavidS]

Who cares which retro BASIC is fastest? Let's just be thankful there are those with enough spare time on their hands to keep them running.

It is all in good fun. The only one that really matters on speed (because of its use) is BBC BASIC VI (and BBC BASIC V). Those are already pretty fast.

It is all in fun, and it is the kind of fun that a lot of people enjoy. It reminds us of the old views. It also helps with future projects of more modern things (what works faster and why can be useful for interpreters of current and future languages).

[RichardRussell]

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.

[Heater]

Do we even have a Big Fibo result for Sophie's ARM BASIC yet?

If one was posted it has passed me by.

What modifications to the code were required to get it to run?

Should I add that code to the fibo challenge repo?

[Soruk]

Do we even have a Big Fibo result for Sophie's ARM BASIC yet?

If one was posted it has passed me by.

What modifications to the code were required to get it to run?

Should I add that code to the fibo challenge repo?

The same changes I made here for Matrix Brandy https://www.raspberrypi.org/forums/view ... 5#p1501541
Just ensure the Next slot is big enough before starting BASIC!