Basic Assembler Branches

I recently came across a problem with a commercial application which is written in BASIC, but has a few assembler routines.

Although this worked for me in the past, it now fails with an error Unknown or missing variable. After some investigation I found it was caused by an assembled line which contained the statement
Bfc

When I changed it to
B fc
(just inserting a space) it all worked as expected.

I have checked the new BASIC manual, and that gives no indication that a space is required – indeed, it says Spaces between mnemonic and first operand are ignored. However, I can understand that using a variable name starting in any of the condition codes, or L or IC, would cause confusion, unless there was a space included.

After some more investigation, I found…

• The program works with BASIC v1.57, but fails with v1.75.
• Comparing v1.57 with v1.29, variables starting in k or K now give No such mnemonic, and any starting in x or X now give Bad register (presumably because of the BX instruction).
• Comparing v1.75 with v1.57, variables starting in f or F now give No such mnemonic, Bad register, or Missing ,.

So it certainly seems that the list of problem variables has increased over time, potentially causing problems for old programs.

I can think of a couple of options…

• Add a warning to the (next) BASIC manual that a blank should always be included?
• Change BASIC to avoid the problem completely?

Any other comments or suggestions?

caused by an assembled line which contained the statement ‘Bfc’

BitFieldClear (BFC) is an ARMv6T2+ instruction. Beware BitFieldInsert (BFI) too. I doubt ARM consider BBC BASIC syntax clashes when they pick new instruction mnemonics!

The fact that the lexing, never mind the parsing, of input can vary from one version of BBC BASIC to another shows up starkly the lack of future-proofing inherent in an ad hoc approach to creating a programming language. I hesitate to talk of language-design in a context where there is no proper specification.

The fact that the lexing, never mind the parsing, of input can vary from one version of BBC BASIC to another shows up starkly the lack of future-proofing inherent in an ad hoc approach to creating a programming language. I hesitate to talk of language-design in a context where there is no proper specification.

Well, strictly speaking the original programs that have no space between the mnemonic and first operator ought to have had a space, for clarity at least, and are now falling victim because the programmer took small liberties which the older revisions allowed in a looser fashion than is now required.

I suppose in older, memory poor, systems saving that handful of bytes was seen as useful – much like the crunching routines discussed a month or so back.

BitFieldClear (BFC) is an ARMv6T2+ instruction.

Yeah, I ran into something similar when rebuilding Zap in that the macro PUSH failed because PUSH was being interpreted as an instruction – even when using non-UAL syntax with the settings specifying an ARMv2 class processor. I regard this as a fault in objasm for interpreting syntax that isn’t applicable for the processor/convention in use.

Likewise BASIC – if the assembler is going to change to support things that it didn’t in the past which may have an effect on the way existing code is interpreted, shouldn’t there be an OPT bit to select what sort of instructions are recognised, to allow extended behaviour to be switched on for programs aware of the enhanced things?

BTW, assembler with no spaces – I pity the programmer that has to maintain such a thing. Was it actually written in such a horrible way, or was that the result of a squisher program?

BitFieldClear (BFC) … BitFieldInsert (BFI)

That explains the particular issue I found.

ought to have had a space, for clarity at least

Programming clarity is not required … but this space seems to be required so the code works. There should be a note in the manual. I will raise a request.

Was it actually written in such a horrible way

Doubt it – there were several assembler instructions on the line. Compression was probably involved – it is a commercial program.

Thanks for all the replies.

Programming clarity is not required

Let’s rephrase that as “clarity isn’t required for a program to work” and I think everyone can agree, just as everyone will agree that comments aren’t required for the program to work, but they help immensely when the code is revisited, perhaps by someone totally different.

… but this space seems to be required so the code works.

“this space now seems to be required so the code works” – basically it was sort of optional before and is now mandatory to clarify things for the assembler.
It’s pretty common – how many Windows programs have you seen fail after MS patched a security hole that the programmer used as a convenient shortcut.

Ooh, a problem solved by Basic Assembler Dialects.

The problem isn’t the coining of new opcodes, it’s the fact that the dialect (or repertoire) of Basic’s assembler changes from release to release. In other words, you have no idea what you’re going to get next week, or on Nigel’s machine…

That’s the point of Dialects, so you can specify exactly what instruction set you meant, and the assembler won’t start misinterpreting your long-established code.

Ooh, a problem solved by Basic Assembler Dialects.

I had thought that to be the case. I suspect there are lots of similar opportunities if people just pause and think. Of course in this instance if the code actually had the formerly optional space the issue wouldn’t have arisen.