CarlGundel
Posts: 30
Joined: Wed Mar 21, 2012 9:53 pm
Contact: Website

Re: Introduction to BBC BASIC

Sat Aug 10, 2019 10:04 pm

RichardRussell wrote:
Sat Aug 10, 2019 9:26 pm
CarlGundel wrote:
Sat Aug 10, 2019 8:49 pm
Liberty BASIC isn't technically an interpreter. It compiles to an object model that executes on top of a bytecoded dynamic translator (similar to Java).
If the language knows about variable names at run time it makes it possible to support an EVAL() function, which accepts an arbitrary numeric or string expression (typically containing variable and perhaps user-defined function names) and 'evaluates it'. Using that criterion Liberty BASIC, like BBC BASIC, is an interpreter because it supports EVAL.
Like I said, splitting hairs, but you make an interesting point.

Liberty BASIC is a compiler in the sense that each statement is converted to an executable form one time, and this executable form is used exclusively to perform the action of the statement. The EVAL() function doesn't use an interpreter, but it uses the compiler at runtime to compile a BASIC expression on demand, but the EVAL() function itself is only compiled once per program invocation.

The actual variables in the compiled form do not know what their variable names are. There is a lookup table maintained so that the correct positions of the values can be resolved by name if needed.

So, more compiler than interpreter. ;-)

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

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 12:00 am

CarlGundel wrote:
Sat Aug 10, 2019 10:04 pm
The EVAL() function doesn't use an interpreter, but it uses the compiler at runtime to compile a BASIC expression on demand, but the EVAL() function itself is only compiled once per program invocation.
If one replaces the words 'compiler' and 'compiled' with 'tokenizer' and 'tokenized' then that exactly describes how the EVAL() function works in BBC BASIC too. So it's back to where on the spectrum you choose to place it. At what point does 'tokenizing' become 'translating' and at what point does 'translating' become 'compiling'? I suspect most people don't think of compiling as something that happens at run time.
So, more compiler than interpreter. ;-)
I suppose it depends on how the description is being used. If what you are interested in is knowing how Liberty BASIC works 'under the hood' then perhaps the term compiler better describes the complexity of that. But if you are more interested in what it tells you about how it performs as a 'black box', i.e. its behavior as observed from outside, then it has the characteristics of an interpreter (variable names are known at run time, relatively large run-time-engine, relatively slow execution speed etc.).

Ultimately it doesn't matter what it is called, it is how it performs that matters.

ZXDunny
Posts: 117
Joined: Sun Jul 08, 2012 7:57 pm

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 11:57 am

RichardRussell wrote:
Sun Aug 11, 2019 12:00 am
CarlGundel wrote:
Sat Aug 10, 2019 10:04 pm
The EVAL() function doesn't use an interpreter, but it uses the compiler at runtime to compile a BASIC expression on demand, but the EVAL() function itself is only compiled once per program invocation.
If one replaces the words 'compiler' and 'compiled' with 'tokenizer' and 'tokenized' then that exactly describes how the EVAL() function works in BBC BASIC too. So it's back to where on the spectrum you choose to place it. At what point does 'tokenizing' become 'translating' and at what point does 'translating' become 'compiling'? I suspect most people don't think of compiling as something that happens at run time.
This. Compiling is something the user initiates as an operation.

SpecBAS also compiles on the fly - to a virtual stack machine, which is then interpreted. Variables are records in memory that, as well as their contents, contain members that describe the name, it's status in FOR statements etc. The editor compiles to discrete units (one per line of code) as you type. The editor "knows" how to find a variable by name while editing but the compiled program uses a memory address. The EVAL equivalents (VAL, VAL$ and EXECUTE) call the compiler at runtime. This can be quite slow, so I also added a function that returns compiled code as a string which can be re-used.

And yes, there's a LOT of caching going on at runtime to keep speed acceptable. it's expensive (relatively speaking, we're not using GBs of RAM here) but memory is cheap and fast.

But SpecBAS is purely an interpreter, albeit one that interprets a kind of bytecode. It compiles, but not how a user would typically recognise it, and not to host architecture.

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

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 1:14 pm

ZXDunny wrote:
Sun Aug 11, 2019 11:57 am
memory is cheap and fast.
Memory is cheap and plentiful, but even on modern CPUs the fastest memory (the Level 1 cache) is still relatively small: 32 Kbytes on this Core i7 laptop, which is comparable with the total amounts of RAM in a 1980s home computer! So keeping the memory footprint of an interpreted language to only a few tens of kilobytes, which might superficially sound pointless when Gigabytes of RAM are fitted, can offer a real benefit.

What I have tried to achieve with my BBC BASIC interpreters (although I don't succeed with the more recent ones coded in C) is for the entire run-time engine to fit into the CPU's instruction cache, which is typically something like 64 Kbytes. There's a performance 'sweet spot' if the run-time engine fits in the instruction cache and the user's BASIC program and data fit into the data cache (preferably the Level 1 cache but if not the Level 2 cache, which is 256 Kbytes on this PC).

So the architecture of modern CPUs is well suited to an interpreted language, and rewards you for keeping bloat to a minimum.

ZXDunny
Posts: 117
Joined: Sun Jul 08, 2012 7:57 pm

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 3:58 pm

I was careful to keep the main interpreter function to less than 32Kb - it deals with the most common "opcodes" and then farms more complex stuff (like drawing/texturing etc) out to other procedures.

But to be perfectly honest, I didn't notice much of a speed-up from when I was running then entire interpreter as one massive case statement. The biggest optimisations came from things like the peephole optimiser and loop unrolling/condensation of common opcode sequences which resulted in an enormous change in how fast this thing is.

That's not to rule out a proper compiler later on - it won't be terribly difficult to do but will be annoying having to support x86/x64 and ARM.

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

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 4:42 pm

ZXDunny wrote:
Sun Aug 11, 2019 3:58 pm
That's not to rule out a proper compiler later on - it won't be terribly difficult to do but will be annoying having to support x86/x64 and ARM.
You would have to support both 32-bits and 64-bits ARM too, at least for as long as the Raspberry Pi is 32-bits. With PCs as fast as they are now I don't really see the need; BBC BASIC is a straightforward interpreter with no 'optimisations' to speak of, yet speed is rarely an issue.

In any case I suspect most worthwhile optimisations would be incompatible with self-modifying code, which having been made possible by the indirection operators and well-documented internals has been a feature of BBC BASIC programming from the start (although not to be encouraged). Only today I've been working with a BBC BASIC library which relies on poking into the stack. Ouch!

As you know I have put my efforts not into speeding up the interpreter but towards reducing the bottleneck of graphics rendering, by exploiting SDL 2.0 and OpenGL's hardware acceleration, and by leveraging the multicore CPUs in most modern machines by running the interpreter and user-interface in separate threads.

ejolson
Posts: 3588
Joined: Tue Mar 18, 2014 11:47 am

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 6:16 pm

ZXDunny wrote:
Sun Aug 11, 2019 3:58 pm
That's not to rule out a proper compiler later on - it won't be terribly difficult to do but will be annoying having to support x86/x64 and ARM.
Maybe you could target WASM web assembly and simultaneously reach near native speeds on both.

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

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 6:47 pm

ejolson wrote:
Sun Aug 11, 2019 6:16 pm
Maybe you could target WASM web assembly and simultaneously reach near native speeds on both.
It's such a pity that web assembly doesn't support multi-threaded applications, at least when I last checked it still didn't, which means I can't easily port BBC BASIC to that platform. Re-writing it as single threaded would be possible but neither straightforward nor desirable.

ZXDunny
Posts: 117
Joined: Sun Jul 08, 2012 7:57 pm

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 9:51 pm

ejolson wrote:
Sun Aug 11, 2019 6:16 pm
ZXDunny wrote:
Sun Aug 11, 2019 3:58 pm
That's not to rule out a proper compiler later on - it won't be terribly difficult to do but will be annoying having to support x86/x64 and ARM.
Maybe you could target WASM web assembly and simultaneously reach near native speeds on both.
SpecBAS is a self-contained environment - there's no need to mess around in the host OS once it's running (which was kinda the point - it was modelled after the 80s machines that booted to BASIC) and compiling programs to the host architecture would still have to be run from inside SpecBAS. Using WASM would likely need to be run from a browser, I would have thought?

...and self-modifying code (at the "opcode" level via PEEK and POKE) isn't possible in SpecBAS - PEEK and POKE only work on memory banks, and the current program is separate from those.

ejolson
Posts: 3588
Joined: Tue Mar 18, 2014 11:47 am

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 10:23 pm

ZXDunny wrote:
Sun Aug 11, 2019 9:51 pm
Using WASM would likely need to be run from a browser, I would have thought?
While a web browser is one possibility, my understanding is that web assembler can also run in a stand-alone virtual machine.

In this respect, WASM seems similar to the JVM and .NET environments with an important difference: WASM was designed to be sufficiently similar to real hardware in such a way that further compiling it into machine code is simple, whereas the JVM and .NET virtual machines were designed around features in high-level languages and employ byte codes that do not translate so directly to machine code for real hardware.

As I'm far from experienced in any of these technologies, hopefully what I've stated above is not too far from the truth.

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

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 10:39 pm

RichardRussell wrote:
Sun Aug 11, 2019 6:47 pm
It's such a pity that web assembly doesn't support multi-threaded applications
I note from here that multi-threaded web assembly applications are 'on the way' and can even be experimented with in Chrome right now, but I don't think we're very near to being able to port BBC BASIC to web assembly quite yet.

ZXDunny
Posts: 117
Joined: Sun Jul 08, 2012 7:57 pm

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 10:44 pm

SpecBAS wouldn't translate well to other hardware, no. There are a lot of operations (such as matrix maths, graphics operations etc) that are performed as a single "opcode" in the VM, and there's the other issue that SpecBAS does not support integer types, only Doubles so the FPU would have to be engaged rather a lot of the time.

Like Richard, I've not received any complaints about speed (mostly because people tend to port older Sinclair Spectrum BASIC programs to it and the speed boost compared to a 3.5MHz z80 is quite noticeable) and it seems to pretty much keep pace with Python in my tests so I'm lately just messing around refining it and adding new features as a I think of them.

Heater
Posts: 13389
Joined: Tue Jul 17, 2012 3:02 pm

Re: Introduction to BBC BASIC

Sun Aug 11, 2019 10:52 pm

"WASM" is some kind of acronym for "WEB Assembler."

But really it's a misnomer, it does not need the WEB or a web browser.

It's an assembly language and instruction set for a hypothetical machine. That machine has an implementation in browsers already, Firefox and Chrome at least.

But there are also implementations that run outside of browsers, that can be used from C or node.js or Rust or whatever.

I'm not sure but I suspect that a WASM machine could be built in actual hardware, at least one guy is trying that in FPGA.

I'm no WASM expert, having only got a couple of experiments compiled from C++ and Rust to WASM working, and I have no idea how it might fit in with any BASIC.

Perhaps a compiler from BASIC to WASM would be cool.
Memory in C++ is a leaky abstraction .

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

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 12:36 am

Heater wrote:
Sun Aug 11, 2019 10:52 pm
I have no idea how it might fit in with any BASIC.
The potential value to me of porting BBC BASIC to WebAssembly is that it would add Chrome OS to the list of supported platforms; currently I don't have a version that will run on a ChromeBook. It's true that some Android applications can be run on that platform but the Android edition of BBC BASIC isn't one of them.

So long as the limitations of WebAssembly aren't an issue (which unfortunately they currently are for BBC BASIC) you can quite easily port a C or C++ application to that platform using Emscripten.

Heater
Posts: 13389
Joined: Tue Jul 17, 2012 3:02 pm

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 6:12 am

I think there is a lot of potential for using web assembly to create very portable applications. I have been copying web assembly "blobs" around from machine to machine, Intel to ARM, Linux to Windows and they just work. No need to have the wasm compilers and such installed everywhere.

But as far as I can tell there is a long way to go between that and creating useful programs with GUI's and so on. Then there is a lot more to deal with in interfacing the wasm blobs to the OS and hardware etc.
So long as the limitations of WebAssembly aren't an issue (which unfortunately they currently are for BBC BASIC) you can quite easily port a C or C++ application to that platform using Emscripten.
What limitations do you have in mind there?

I could imagine compiling BASIC to WASM and hence having a very portable code, but still it needs that GUI to run it which will need porting to every desired platform.

Compiling C++ to WASM with emscipten works really well. See my million digit Fibonacci calculator that runs C++ in the browser: https://otaniemi.conveqs.fi:3000/public/fibo.html Performance is pretty impressive.
Memory in C++ is a leaky abstraction .

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

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 8:38 am

Heater wrote:
Mon Aug 12, 2019 6:12 am
But as far as I can tell there is a long way to go between that and creating useful programs with GUI's and so on.
Not so much if the GUI is created using SDL 2.0, because Emscripten can easily pull in the SDL libraries when building the WASM binary.
What limitations do you have in mind there?
You really should read the last few messages before joining in! I stated only a few posts back that it was the lack of support for multi-threaded applications.
I could imagine compiling BASIC to WASM and hence having a very portable code, but still it needs that GUI to run it which will need porting to every desired platform.
Not in the case of BBC BASIC for SDL 2.0. The GUI should 'just work' when specifying the appropriate switches to Emscripten:

Code: Select all

emcc -s USE_PTHREADS=1 -s WASM=1 -s USE_SDL=2 -s USE_SDL_TTF=2 -s USE_SDL_NET=2
I went through this whole exercise months ago and built a complete BBC BASIC binary (as an HTML5 file) using Emscripten, but it doesn't run. I'll revisit it sometime when the multi-threaded support is more mature.

Heater
Posts: 13389
Joined: Tue Jul 17, 2012 3:02 pm

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 9:48 am

RichardRussell,

Sorry, I missed the "multi-threaded" point. I'm not used to the idea that BASIC programs might be threaded !

If I understand correctly emscripten will compile your application and the SDL into Javascript or WASM and wrap the whole thing in Javascript bindings for use in a web page or node.js. I currently do that (minus the SDL) for a big blob of complicated C++ that I wanted to run fast in a node.js server.

Unless I have missed a point, if you want to make something more like regular application that leaves the problem of connecting up the emscript SDL image to a real window.

I'm not sure where you would want to go with this.
Memory in C++ is a leaky abstraction .

ZXDunny
Posts: 117
Joined: Sun Jul 08, 2012 7:57 pm

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 9:59 am

SpecBAS also runs multi-threaded, but not for the language itself. I run a thread separately from the interpreter that renders the display at 50Hz, so I don't have to bother issuing commands to update the screen (it's analogous to the Spectrum's ULA in that regard). And there's various threads spawned to watch stuff and signal the interpreter for all sorts of things.

I don't think I'll be moving to WASM just yet :D

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

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 11:11 am

Heater wrote:
Mon Aug 12, 2019 9:48 am
Unless I have missed a point, if you want to make something more like regular application that leaves the problem of connecting up the emscript SDL image to a real window.
I don't have any need to make "something more like a regular application" because BBC BASIC is already multi-platform (courtesy of SDL 2.0) and there's nothing wrong with those versions. It's specifically to support ChromeBooks, which are widely promoted as a replacement for a conventional desktop PC, that a WASM version would be useful.

I'd be entirely happy for it work 'in a browser' because that's what's needed for that platform, and since WebGL is to all intents and purposes compatible with OpenGL ES2 the graphics display aspect is pretty much a non issue (apart from the missing glLogicOp which is admittedly a pain for BBC BASIC).

Heater
Posts: 13389
Joined: Tue Jul 17, 2012 3:02 pm

Re: Introduction to BBC BASIC

Mon Aug 12, 2019 11:19 am

OK, gotcha, sounds like a cool idea.
Memory in C++ is a leaky abstraction .

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

Re: Introduction to BBC BASIC

Tue Aug 27, 2019 2:57 pm

For those wanting to use BBC BASIC on the Raspberry Pi 4, who may have been affected by the glLogicOp() function not working (and hence BBC BASIC's GCOL statement being broken), I'm pleased to confirm that this Mesa update resolves the issue and restores BBC BASIC for SDL 2.0 to a fully functional state:

https://www.raspberrypi.org/forums/view ... 6&t=249650

ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: Introduction to BBC BASIC

Tue Aug 27, 2019 11:27 pm

Why doesn opengl need to be used for BBC basic on the Pi 3?
It messes with my screen resolution (I prefer to have it on 720p, and Raspbian doesn't give me the option anymore to change the resolution).

User avatar
scruss
Posts: 2499
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Introduction to BBC BASIC

Wed Aug 28, 2019 1:58 am

ProDigit wrote:
Tue Aug 27, 2019 11:27 pm
Why doesn opengl need to be used for BBC basic on the Pi 3?
Speed. It's painful without it. Plus, we have accelerated graphics, so why not use them?

Resolution setting's available from raspi-config: 7 Advanced Options → A5 Resolution
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

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

Re: Introduction to BBC BASIC

Wed Aug 28, 2019 8:23 am

scruss wrote:
Wed Aug 28, 2019 1:58 am
Speed. It's painful without it. Plus, we have accelerated graphics, so why not use them?
In any case I don't have any choice in the matter: it's BBC BASIC for SDL 2.0 and SDL2 uses OpenGL as the rendering backend when running on Linux (including Raspbian). So it's always using OpenGL, either hardware-accelerated OpenGL when FKMS is enabled or software-emulated OpenGL (mesa) otherwise.

Using OpenGL also opens up possibilities which would not otherwise be available to the BBC BASIC programmer, such as hardware-accelerated 3D graphics and shader programming (both achieved by direct calls into OpenGL using the SYS statement). There are several example programs supplied that illustrate what can be achieved.
ProDigit wrote:
Tue Aug 27, 2019 11:27 pm
It messes with my screen resolution (I prefer to have it on 720p, and Raspbian doesn't give me the option anymore to change the resolution).
The VC4 driver used on the RPi 3 has had a few issues with things like overscan and the camera but I think it has got better over time. On the RPi 4 the V3D driver is enabled by default so I would not expect it to restrict your choice of resolution.

ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: Introduction to BBC BASIC

Wed Aug 28, 2019 10:12 pm

I would have been ok, if it just didn't change my desktop resolution.
I know there's probably a way to manually set it to the resolution I prefer.. But I haven't gotten to it yet.

Return to “Other programming languages”