BBC BASIC with VFP/SIMD assembler 0.01

Today we have released an Alpha test version of BBC BASIC with the VFP/SIMD assembler. Further information is available in the post on the TBA website.

We will continue testing the assembler as part of the ongoing TAG development and will submit the code for potential inclusion into CVS in due course.

Other plans for BBC BASIC are on hold as the legacy source code does not make it at all easy to enhance the BASIC language. We are considering other options.

Nice work! Now if only I had the time to write something that makes use of this ;-)

Wahay!

legacy source code does not make it at all easy to enhance the BASIC language.

Is Brandy BASIC worth looking at?[1] [2] (Note that the built-in assembler is not included.) Has anyone tried this on the BeagleBoard? The code doesn’t seem to have been touched for a few years and it would perhaps be too slow for your purposes anyway, Alan.

Other plans for BBC BASIC are on hold as the legacy source code does not make it at all easy to enhance the BASIC language. We are considering other options.

It’s probably a dumb idea, but have you thought of looking at what it would take to port Mono to RISC OS. If it was possible it would allow you to write program in Visual Basic for RISC OS.

Given that an ARM port of Mono exists, it certainly looks like something that might be worth pursuing, although reading between the lines, it may be pretty slow/cumbersome (but that seems par for the course with non-RISC OS/Phone stuff on ARM cpus). The lack of cross-platform development options in the 90s ended up being a major problem for Acorn (their lack of Java/Macromedia Director development progress).

However, the problem (as always) is finding people to work on the project :(

Brandy Basic? Nah.

Mono is a good idea, though not specifically for Visual Basic.

Other plans for BBC BASIC are on hold as the legacy source code does not make it at all easy to enhance the BASIC language.

You should try working with no source at all mate. ;-)

I was pretty horrified when I finally saw the Basic source though. Yeah, look at that, the insides of Replay and ChangeFSI and your faith can waver slightly. :-p

You should try working with no source at all mate. ;-)

Sure, well in my 20 years of working as a developer I’ve pretty much tried it all when it comes to reverse engineering and hacking around old code. Sometimes it’s easier just to read the dis-assembly as the source can be horribly confusing when very badly constructed!

More important than all that is a big dose of realism in what can be achieved when we all work on this thing part time, which is perhaps where Andrew was leaning as there are very few people actually working on anything major.

On that very note, while I admire the optimism that we could just “port” something like Mono, there are a lot of missing pieces of the underlying operating system that make this kind of port a very large challenge…

When porting mono, two things are important:
if the jit has been ported to the wanted cpu
if the os supports a correct implementation of POSIX/pthreads.

Nice!

IIRC didn’t Martin make some progress on the pthreads front in years gone by, Alan?

IIRC, Martin Piper’s work on pthreads was initially used as a base for the UnixLib implementation. Not sure how much of it survived in the end, I remember discussions about a whole bunch of problems. Anyway, I think pthreads support is now mature in UnixLib.

An update to the VFP assembler (0.02) has been released that fixes a few bugs.

I’ve been discussing threading with Martin and a few other people after reviewing all the previous forum posts here on the subject. When we have something to report I’ll start a new thread as it’s too large a subject for this thread on the VFP assembler.

Version 0.03 released today with a few more bug fixes and minor enhancements

Great work. Finally I could port my VFP Mandelbrot version from ExtASM to your enhanced Basic Assembler. It can be found here: FracVFP_Basic
It works the same like my ExtASM app. I got some trouble porting my much faster but more complicate NEON version, I’ll see what’s the problem. Though I don’t have time before mid next week…hopefully I get it fixed then :-)

Something that’s just occurred to me that perhaps someone here can answer:

When you extend the BASIC assembler, is each new mnemonic given a unique token number? Indeed, is assembler tokenised in the same way as normal keywords? And if so, who, if anyone, is in charge of allocating the token numbers?

When you extend the BASIC assembler, is each new mnemonic given a unique token number?

The short answer is no, tokens are not added or used. Problems only occur when a keyword starts with an existing token. Tokens are not used part way through a keyword as it might well be a variable name. For example VMOVEQ would not contain V followed by the token for “MOVE”, where as the ARM instruction MOVEQ would contain the token for MOVE followed by a Q.

With VFP there was only VDUP that caused problems as it started with the token for VDU. It was made worse as VDUP.16 ended up being changed to VDUPRINT16 so in this case I changed it to VDPL to work around the problem.

The VFP assembler code uses some simple string matching to look for mnemonics, and for VFP they all start with at least 4 chars making it a very simple task.

As has been stated in another thread, adding tokens is generally a bad idea as it tends to break lots of things, particularly code editors. I’m certainly not aware of any “authority” on tokens, my guess is they just exist in various large tables in the BASIC source code and the tokenise / detokenise code.

Thanks, Alan. So, no assembler commands are tokenised at all? “MOV” is just “M”, “O”, “V”? I’d naively assumed that they would be…

With VFP there was only VDUP that caused problems as it started with the token for VDU. It was made worse as VDUP.16 ended up being changed to VDUPRINT16 so in this case I changed it to VDPL to work around the problem.

I’m sure the assembler can currently cope with MOVEQ though (the original ARM opcode, not the VFP one) without mistaking it for MOVE + Q. Can you not copy the way it handles that for VDUP?

As has been stated in another thread, adding tokens is generally a bad idea as it tends to break lots of things, particularly code editors. I’m certainly not aware of any “authority” on tokens, my guess is they just exist in various large tables in the BASIC source code and the tokenise / detokenise code.

It’s much worse than that. Individual token numbers are woven throughout the code and used for state representation in various memory and stack structures. Specific tokens are checked for in many places (ELSE is particularly ubiquitous).

However, the simplest argument against adding ANY new keywords is backwards compatibility – you may think that “RESUME” might make a good keyword, but if so, any program containing a “RESUMES” variable can never be edited again. (Anyone using all-capital variables in BBC BASIC ought to be shot).

I’m sure the assembler can currently cope with MOVEQ though

It certainly does cope, but only once it has been tokenised to MOVE,“Q”. EOR,anything and OR,“R” are similar.

I’m sure the assembler can currently cope with MOVEQ though (the original ARM opcode, not the VFP one) without mistaking it for MOVE + Q. Can you not copy the way it handles that for VDUP?

The problem is the P. not the VDU. It makes VDUP.16 expand to VDUPRINT16 when you save it from a text editor. VDU is a token and P. is short for PRINT which is also a token, so you end up with two tokens in the BASIC file.

I managed to port the NEON code from my Mandelbrot application from ExtASM to your Basic Assembler. No more problems occurred with your Version 0.03 :-) You can find the applications here: Frac_NEON_VFP_Basic

It includes also the enhanced VFP version. I included the CPU clock detection in my code done by Jeffrey (hope it’s okay…) and some results display stuff. Any comments welcome. Time to start more NEON coding :-)

No more problems occurred with your Version 0.03 :-)

That’s fantastic, it’s great to hear it’s being used. It seems we might be edging towards a release 1.0 that gets checked in to CVS (not that I have access yet!) although I expect there must be a few more bugs lurking. I’m also considering adding all the other missing ARM instructions from the ARMv7 manual. Also the help text needs updating and that’s all a bit messy.

Within TBA we’ve not actually used the new instructions much. Our NEON based 3D calculation engine is currently only a design, with some BASIC prototyping to test concepts. Hopefully it will get some time allocated in the not too distant future.

I’m currently reading through some of the RISC OS Kernel code trying to get my head around some of the concepts and challenges relating to threading in particular. My knowledge of the ARM architecture is lacking as I’ve never looked at things at such a low level.

Since all upper case key words are tokenised in BASIC perhaps switching to lower case for assembler is a reasonable option?
There are no drawbacks since old assembler code already works and new assembler that supports VFP and NEON has not been used by anyone yet. It would allow the use of many new assembler operations without interference with BASIC.
assembler is not BASIC so the move towards lower case assembler would even help the readability of the code.

To emphasize the difference between the use of tokenisation and assembler, tokens are used to optimize speed where as assembler is used only once during the conversion of assembler to code. In that respect the move to lower case assembler statement seems more logical too.

Within TBA we’ve not actually used the new instructions much. Our NEON based 3D calculation engine is currently only a design, with some BASIC prototyping to test concepts.

Regarding that, do you use fixed point or floating point math for the 3D stuff ? You may have noticed that there’s no real native SQRT or SIN/COS for NEON. At the moment I’m testing different routines found on the web dealing with that. For SQRT there are useful instructions that minimize the work (VRECPE/S and VRSQRTE/S), but for SIN/COS there’s a need for a decent approximation.

To show the different approaches for SQRT and results I coded a small example comparing NEON, VFP and FPA/FPEmu. You can find it here: SQRT_variants

You can see that the approximation for NEON produces a small slight difference at one digit, but still may be good enough…I’m not really a mathematician to judge that in total…for sure there are other approaches for approximation, and I guess at least in the latest ARM GCC there must be some in the math libraries.

Regarding that, do you use fixed point or floating point math for the 3D stuff ?

The 26bit version of TAG used integer maths and was all limited to 32bits. So there was around 22bits of accuracy for most operations. For TAG32 we’ve been looking at both 32:32 fixed precision and double float, depending on the performance we see when we get it up and running.

Currently I am leaning towards using double floats for accuracy, and because the NEON/VFP in the Cortex A15 will (according to ARM at least) be faster than what we have today. This is one reason why we’re also looking at threads as it’s handy to use the multiple cores as rendering pipelines (sub-setting the screen and aspects of the scene).