BBC BASIC with VFP/SIMD assembler 0.01

Since all upper case key words are tokenised in BASIC perhaps switching to lower case for assembler is a reasonable option?

All assembler instructions are currently case insensitive so I’m not convinced this is a good solution – we do need all the existing code to compile and to keep things as simple as possible. It’s only one instruction that’s been a problem and it’s not difficult to search and replace any code that’s ported into the BASIC assembler.

At some point I’d love to re-write BBC BASIC without tokens and a JIT, but that’s currently a dream due to the amount of work involved. As someone rightly suggested, porting Mono might be a better use of time in the long run as .NET is far more standard in the wider world.

I know this thread is about BBC BASIC, but it seems to me to be an opportune moment to point out that RiscLua has been around for a decade now. It is as easy to use as BASIC but is cleaner and has far more powerful features (IMHO). Furthermore there is now an ARM version of LuaJIT. At the moment it needs GCC 4.2 to compile, which is not yet available on RISC OS. However, I do not think I am being over-optimistic in saying that a JIT version of RiscLua is a far more feasible exercise – and a worthwhile one. Its FFI interface should be the equal of BASIC’s assembler, allowing the programmer to mix Lua, ARM assembler and C. So come on you programmers, I need a hand here!

On a completely non-RISC OS-topic (unless someone fancies a port of the JamVM of course): can Lua also run an a JVM, equivalent to other scripting languages like Groovy or Jython?

See http://lua-users.org/wiki/LuaImplementations which mentions Kahlua, Mochalua, luaj and Jill – all Java implementations of Lua.

The problem is the P.

The problem is the nutter who decided to use a full stop in a mnemonic.

I’m not joking. We’ve had perfectly acceptable B and H postfixes for nearly twenty years. What’s this .8 .16 .32 nonsense about?

I’d go with VDUPL, VDUP, VDUPH and VDUPB and ARM be damned.

Feel free to insert I, F, U, S as appropriate. (I and S the defaults)

ie

VADDIB => VADD.I8
VADDIH => VADD.I16
VADDI => VADD.I32
VADDIL => VADD.I64
VADDF => VADD.F32
VADDLSB => VADDL.S8
VADDLS => VADDL.S32
VADDWSB => VADDW.S8

etc. Or use an underscore instead

Furthermore… it occurs to me that any assembly with full stops in close proximity to numbers could run foul of BASIC compressors, because of this:

> vdup = 12
> PRINT vdup.16
12 0.16

See what I mean? Full stops and numbers in assembly are Very Bad Indeed.

Lots of good comments.

I very much doubt ARM even considered BBC BASIC when they designed the later instruction formats, and Ben did say he had asked them about it and didn’t get anywhere. It’s only because BBC BASIC uses tokens in it’s saved format that we have a problem that can’t be worked around.

While I don’t love the ARM choice of syntax either, that’s kind of just the way it is, and there isn’t anything we can do about it. Adding all those instructions and only having one token related issue with syntax I can live with…

Our wish list has a few things like handling extended notation for data-types, but nothing particularly important as all instructions can be compiled.

The problem is the nutter who decided to use a full stop in a mnemonic.

Like it or not, it’s a growing convention in assemblers, not just ARM – I’ve seen the same thing used in other architectures like SH-4 and MSP430. And having updated objasm for all the new opcodes, I can see that the convention makes the assembler’s job a lot easier – no more guessing where the opcode ends and the flags begin.

There are other contributing factors. The data type qualifiers in VFP/NEON instructions refer to the data type of elements of vector operands, not to the operands themselves, so they’re not quite the same thing as the flags on the main ARM instructions. And the way that the number of data types has mushroomed means that flag letters would be under more pressure – there are 8/16/32/64-bit integer (signed, unsigned and unspecified), 16/32-bit fixed point (signed and unsigned), 16/32/64-bit floating point, 8/16-bit polynomial, and untyped 8/16/32/64-bit data types.

ARM even tried it your way at first. The results were horrible: pre-UAL syntax ended up with opcodes like these:

FSHTOD, FSHTOS, FSITOD, FSITOS, FSLTOD, FSLTOS, FTOSHD, FTOSHS, FTOSID, FTOSIS, FTOSIZD, FTOSIZS, FTOSLD, FTOSLS, FTOUHD, FTOUHS, FTOUID, FTOUIS, FTOUIZD, FTOUIZS, FTOULD, FTOULS, FUHTOD, FUHTOS, FUITOD, FUITOS, FULTOD, FULTOS

where UAL uses the much more manageable

VCVT{B|R|T}

to replace all of those.

A “growing convention”? Really?? Somebody’s never heard of the Motorola 680×0, then!

In at least the integer instructions (I haven’t any experience with the floating point), the full stop was enforced in most mnemonics (and, in the case of memory access, operands as well), indicating the width of the data – so you would have move.b, move.w & move.l, add.b, add.w & add.l, etc. A load instruction might look something like “move.w (a0,d0.w),d1” to load 16 bits from address a0 plus offset d0 into register d1.

Ironically, Acorn initially tried the (then very popular) 680×0 processor and came to the conclusion that it was so inefficient and memory bandwidth was so appalling a 6502 was actually faster – which indirectly led to the design of the ARM processor in the first place!

Use an underscore then but please, no dots.

Somebody’s never heard of the Motorola 680×0

Touche! Yes, I admit, I haven’t had the pleasure of writing assembly in every architecture in existence. :)

Use an underscore then but please, no dots.

I think I’m inclined to agree – it seems like using dots in BASIC assembler is asking for trouble. VDUP might be the only problematic opcode right now, but there’s nothing stopping ARM from adding more in future.

Version 0.04 of the BASIC VFP/SIMD assembler has been released for download

Fixed VLDx/VSTx syntax error due to missing comma
Fixed register type case-sensitivity
Fixed listing missing final character
Fixed optional ‘ignored’ data-type on data-processing instructions
Fixed condition codes

Version 0.04 at 600MHz on the Touch Book gives the following with SQRT_variants: 0.61s, 1.02s and 12.71s for NEON, VFP and FPA/FPEmu respectively.

Holiday Time

…So I’ll ask here instead.

If the code compiled with the VFP/SIMD-enhanced BBC BASIC assembler is saved, then should it run from a reboot with just the current ROOL BASIC installed? AIUI the assembler enhancement provides an interface for VFP/NEON, which is then handled by the new OS commands already introduced.

May be I can answer, too, if Alan is on holiday…if you have your assembler code written with your Basic code and within that you save your assembled code from memory to a stand alone executable piece of machine code, that executable runs totally without the initiation of the enhanced Basic assembler.

I just guess you have to make sure to include the context switching code, that Alan also provided as a macro to include at start and end of your code, but that’s also true if you run the code directly from your Basic code.

you have your assembler code

It won’t be my code, as I don’t have enough knowledge for that! However, I’m interested in experimenting so will try with, e.g. Alan’s or your code. Thanks for the help.

I made a collection of my example code for the enhanced BBC Basic Assembler. It includes the known FracNEON, FracVFP and SQRT variants plus a new one dealing with SIN variants (to show different methods for SIN approximation/calculation with NEON found on the web). You can find it at my web page

@Trevor: If I find time this week I’ll try to add an example that saves “stand alone” code from the Basic Assembler. I should have something like this to convert from my good old CodeCraft Competition entries :-)

Like proposed I added an example that saves some stand alone code after assembling it. It’s an adaption of my old 1 KByte Intro for the Codecraft#3 compo in 2001 called “BiLiZo”, you can find it in the collection of examples

I don’t use much NEON instructions, only for copying/ORR-ing data. Should adapt the bilinear zooming someday to NEON. That could give some nice speed increase. But even also now it runs smooth at 800*600*8bit :-) Make sure you got 2 MByte in your Next slot before starting the executable.

Version 0.05 of the BASIC VFP/SIMD assembler has been released to fix a bug with VLDM/VSTM register list sizes

adaption of my old 1 KByte Intro for the Codecraft#3 compo in 2001 called “BiLiZo”

Works fine here with BASIC VFP/SIMD assembler 0.05, running standalone without the enhanced BASIC as you say above. Also works full screen at 1024×600 on the Touch Book. Your original entry seems to be archived (along with some others) but doesn’t seem to be at pouet.net – what do you think?

Version 0.06 of the BASIC VFP/SIMD assembler has been released to fix various bugs reported by Jeffrey.

Many thanks to all who continue to test the assembler and report bugs.

At some point I’d love to re-write BBC BASIC without tokens and a JIT, but that’s currently a dream due to the amount of work involved.

I have only just started monitoring these forums, having installed RPCEmu from a stick, so I come late to this thread. I hope I have something to add.

In reply to the above, I must refer to my Basalt extensions that are already implemented with a JIT. Indeed, libraries can be fully in text form and they will be JITted to BBC BASIC and Basalt. So, if you like, that work is done. Although the available version dates back to 2003, there is a much more extensive and efficient version sitting on my harddisc, waiting to be properly debugged and published.