gtoal
Posts: 111
Joined: Sun Nov 18, 2012 12:02 am

Re: BBC Basic compilable?

Tue Feb 04, 2014 10:19 pm

No-one has mentioned the reason that BBC Basic is effectively not a compilable language: it has the "EVAL" statement where you can do things like input a string from a user (eg "whatever") and execute a command by evaluating "FNwhatever". Although in principle it could be compilable, it could only be done by including a complete compiler along with the runtime.

A subset of BBC basic without EVAL and a couple of other constructs is easily compilable.

G

User avatar
RichardRussell
Posts: 580
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC Basic compilable?

Tue Feb 04, 2014 11:06 pm

gtoal wrote:No-one has mentioned the reason that BBC Basic is effectively not a compilable language: it has the "EVAL" statement
Indeed so. The assembler also poses difficulties for a would-be compiler - you can't 'pre assemble' at compile time because the 'source code' may well be dependent on values calculated at run time. In fact it's one of the unique features of BBC BASIC: values known only at run-time can be incorporated as 'constants' in the assembled code, with potential performance benefits.

Richard.

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: BBC Basic compilable?

Fri Feb 07, 2014 3:01 am

SiriusHardware wrote:Hi gents, thanks for the interesting replies. My reasons for posing this question were twofold -

One, that code assembled or compiled to executable code should always run faster than the interpreted alternative - although of course that depends upon how it is done. In the old days the interpreter would work through every line of code working out what to do each time that line of code was encountered - a terrible waste of processor time.
That's the definition of an interpreter. A pure interpreter would always interpret each line as it came to it (with a performance hit to boot). BBC BASIC is a little better than that in that (at least) it "tokenises" recognised keywords before they're run - so that when interpreting a line it doesn't have to deal with a five character keyword (like INPUT) when doing the interpretation - instead it has a single byte tokenised character to check.
SiriusHardware wrote:I suppose that on modern machines with memory to burn, the interpreter could do a single initial pass through the whole source code effectively assembling or compiling it to a ready-to run image in RAM, and then run it.
I don't think it's a memory issue, in fairness. It was more an issue of speed. On older machines compiling a program would take an appreciable amount of time (anywhere from a second or two for a simple program up to several minutes for long ones).

When you give a command to run (in a Compiler) the entire program has to be analysed before ANY of it can be run. An interpreter (on the other hand) can start the moment you type RUN (after all it only needs to concern itself with analysing one line at a time), even if the program is 100,000 lines long the Interpreter still gets to start virtually instantly - whereas the compiler would sit there churning away for minutes.

Modern computers are so much faster that unless a program is pretty big and complicated an interpreter and compiler would in many instances seem to start simultaneously - so the downside of compiling isn't as obvious (also modern compilers are smart they don't compile any code that hasn't changed since the last compile).

The big thing is a compiler checks ALL the program and then can verify if it is all syntactically correct (an interpreter doesn't it only "looks" at the bits it executes). For example if I made a mistake in a bit of BASIC but it was rarely called - then most times the code would run correctly (the interpreter wouldn't complain as it never was "tripped" up by the error it didn't reach). But if (on another occasion) the interpreter DID enter that invalid code fragment then it would fail with a runtime error.

This makes testing interpreted programs a bit of a pain (you need to check ALL parts are reached and that they are all correct). In complex code that can be difficult.

A compiler, on the other hand, would go through the whole program before it's run- checking that each part was valid - and if there were one or more errors it would list them all. If you like the compiler "helps" you find the errors rather than letting your users find them.....

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: BBC Basic compilable?

Fri Feb 07, 2014 3:15 am

gtoal wrote:No-one has mentioned the reason that BBC Basic is effectively not a compilable language: it has the "EVAL" statement where you can do things like input a string from a user (eg "whatever") and execute a command by evaluating "FNwhatever". Although in principle it could be compilable, it could only be done by including a complete compiler along with the runtime.

A subset of BBC basic without EVAL and a couple of other constructs is easily compilable.

G
This was a limitation present in the old ABC (BBC BASIC Compiler) - no EVAL and some other restrictions. You could write code that would work on it - so long as you kept within the restrictions. Several applications (including an Antivirus program) were written using it.

User avatar
RichardRussell
Posts: 580
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC Basic compilable?

Fri Feb 07, 2014 9:36 am

AMcS wrote:A pure interpreter would always interpret each line as it came to it (with a performance hit to boot). BBC BASIC is a little better than that in that (at least) it "tokenises" recognised keywords before they're run - so that when interpreting a line it doesn't have to deal with a five character keyword (like INPUT) when doing the interpretation - instead it has a single byte tokenised character to check.
In fact the benefit of tokenising is even greater than you suggest, because once the keywords have been converted to single-byte tokens many of the spaces in the program become superfluous as far as the interpreter is concerned. So the program can be made even shorter, and will run faster, by eliminating those spaces.

It's interesting to note that the architecture of modern processors is well suited to interpreted languages and can give another performance boost. Specifically, CPUs tend to have a relatively small on-chip 'instruction cache' (perhaps 64 Kbytes or so) which can be accessed far faster than main memory. If you can squeeze the entire BBC BASIC interpreter into that cache it will run very quickly, and the relatively slower 'data' memory accesses are then only needed for the tokenised BASIC program - which byte-for-byte will be much smaller than the equivalent compiled machine code would be.

In fact the recent trend has been away from traditional 'compiled' languages, in which the entire program is translated to machine code, towards a two-step process of first compiling to a compact processor-independent 'byte code' which is then executed by a 'run time engine': the .NET framework with its Common Language Runtime is an example. Not that different from BBC BASIC if you think about it!

Richard.

P.S. Yes I know much of this was stated earlier in the thread but that was over a year ago!

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: BBC Basic compilable?

Fri Feb 07, 2014 12:10 pm

RichardRussell wrote:In fact the benefit of tokenising is even greater than you suggest, because once the keywords have been converted to single-byte tokens many of the spaces in the program become superfluous as far as the interpreter is concerned. So the program can be made even shorter, and will run faster, by eliminating those spaces.
I am not sure about BB4W, Richard, but ARM BASIC does more pre-processing than that. The tokenisation is usually done on file saving [1], but at runtime it removes unwanted spaces, REMs and blank lines. There are also other features that mean a program line may not need to be fully interpreted when it is encountered repeatedly. There are also crunching programs that can reformat a program to run faster. All together, compiling BASIC only has serious advantages in special circumstances and can end up slower.
[1] The Zap editor does it on text entry, I think

User avatar
RichardRussell
Posts: 580
Joined: Thu Jun 21, 2012 10:48 am

Re: BBC Basic compilable?

Fri Feb 07, 2014 1:08 pm

Steve Drain wrote:I am not sure about BB4W, Richard, but ARM BASIC does more pre-processing than that. The tokenisation is usually done on file saving [1], but at runtime it removes unwanted spaces, REMs and blank lines.
BB4W does the same when compiling (by default; it's configurable). The model is rather different from ARM BASIC, of course, because BB4W is an IDE which supports 'immediate mode execution' for development and debugging, and 'compilation' to a standalone EXE for deployment. Therefore it doesn't bother to do any crunching or other optimisation (apart from tokenisation) when run from the IDE, when speed and file size aren't so critical, but it does when building the EXE.

With BB4W there's no need for the 'crunching' operation to be reversible, so as well as the steps you mention all variable, procedure and function names are automatically abbreviated to as few characters as possible, and distributed evenly across the alphabet to take maximum advantage of BBC BASIC's initial-character-indexed lookup mechanism.

The variable abbreviation probably has as much impact on performance as removing surplus spaces and REMs etc. It also has the 'psychological' advantage of not making you feel you should use short variable names in the most speed-critical sections of code!
There are also other features that mean a program line may not need to be fully interpreted when it is encountered repeatedly.
Notoriously the pre-parsing of the formal parameters of PROCs and FNs! I don't do that in BB4W because it doesn't work properly when indirected variables are used as formal parameters, as I'm sure you're aware. ;-)

Richard.

Steve Drain
Posts: 105
Joined: Tue Oct 30, 2012 2:08 pm
Location: Exeter UK

Re: BBC Basic compilable?

Fri Feb 07, 2014 5:29 pm

RichardRussell wrote:Notoriously the pre-parsing of the formal parameters of PROCs and FNs! I don't do that in BB4W because it doesn't work properly when indirected variables are used as formal parameters, as I'm sure you're aware. ;-)
I am, indeed, and just think about compiling that. :)

AMcS
Posts: 184
Joined: Sun Jan 06, 2013 11:23 am
Location: Dublin, Ireland

Re: BBC Basic compilable?

Thu Feb 13, 2014 8:56 pm

RichardRussell wrote:In fact the recent trend has been away from traditional 'compiled' languages, in which the entire program is translated to machine code, towards a two-step process of first compiling to a compact processor-independent 'byte code' which is then executed by a 'run time engine': the .NET framework with its Common Language Runtime is an example. Not that different from BBC BASIC if you think about it!
Thanks for your insights on the BBC compiling process !

As I understand it while there are similarities, the .NET Just In Time Compiler (Jitter) can selectively just "compile" those called methods of assemblies (so you take less of a "hit" on performance as only the bits called are compiled and when compiled any further references during the runtime of the assembly are to the "compiled" version of each method).

The .NET performance is pretty good (and better than I would have expected as a result of such steps, the first time a piece of code is run it is slower - but once "jitted" it is considerably faster).

There is also a full native compiled process (using NGEN.EXE) that will take a complete assembly and convert it all from MSIL to the native machine language of the particular platform, this being done at install time. That is closer to a traditional compiler (albeit via the two step process you described earlier) the product though is code that is optimised native code and which is persisted (cached) for later use.

Return to “RISCOS”