BASIC assembler and Basalt

I have a problem to solve and would like to solicit suggestions.

In another topic I have been asking about using SWIs in user mode to interact with BASIC. This arises from a very long-standing task on my to-do list – to modularise Basalt. Before doing that, I need a way to call the internal routines in the Basalt module from external programs. If this were done, there would be the immediate possibility of using them in BASIC assembler, which might have some benefits in making coding simpler and more flexible. ¹

There is no problem in providing the address of a branch table to the routines, from which BASIC variables can be created for BL instructions. But, Basalt has always been designed to be able to be replaced by a later version without causing programs using it to crash. You can see that if Basalt were replaced, the branches would no longer be valid. Furthermore, code assembled in BASIC and saved for later use, including modules, could not rely on those branches.

Using SWIs to call the routines works well, but incurs the inevitable overheads, which might be acceptable for the convenience gained. What I want, though, is a means to branch to the routines like the SWI dispatch, but without the overheads (and the moon on a stick). ;-)

I can conceive a method that stores the table address in a register, that somehow gets updated when Basalt is (re)loaded, but when writing BASIC assembler and using the branches to its internal routines, dedicting a register for that is not at all convenient.

So, is there some method that I cannot see that has solved similar problems in the past?

¹ Here is something of what I mean. Notice that USR can take parameters and return float and string values, and CALL can take values as parameters as well as avoiding the awkward decoding of the variable list.

You do not have to be using Basalt itself to call the SWIs.

PROCcode
PRINT (USRinteger:9.9,55)*2
PRINT (USRfloat:9.9)*2
PRINT (USRstring:"9.9")
CALLcall:"Hello world!"

END
DEFPROCcode
 DIM code% 255
 FOR F%=0 TO 2 STEP 2
  P%=code%
  [OPT F%
  .integer
  STMFD   r13!,{r14}
  SWI     "Basalt_StartUSR"
  SWI     "Basalt_ReadInteger"
  MOV     r1,r0  
  SWI     "Basalt_ReadInteger"
  ADD     r0,r0,r1
  SWI     "Basalt_ReturnUSR"
  LDMFD   r13!,{pc}
  .float
  STMFD   r13!,{r14}
  SWI     "Basalt_StartUSR"
  SWI     "Basalt_ReadFloat"
  SWI     "Basalt_ReturnUSR"
  LDMFD   r13!,{pc}
  .string
  STMFD   r13!,{r14}
  SWI     "Basalt_StartUSR"
  SWI     "Basalt_ReadString"
  SWI     "Basalt_ReturnUSR"
  LDMFD   r13!,{pc}
  .call
  STMFD   r13!,{r14}
  SWI     "Basalt_StartCALL"
  SWI     "Basalt_ReadString"
  SWI     "Basalt_ReturnCALL"
  LDMFD   r13!,{pc}
  ]
 NEXT F%
ENDPROC
END

Hmmm, could you construct a jump table in a Dynamic Area? Then, when a client asks for the addresses for jumping into Basalt, Basalt actually returns the DA table.
Then, if Basalt is reloaded, restarted, powered up, etc etc it can notice that the jump table already exists, and then just replace the table with one of its own.

So then the client can call into Basalt with table%+offset (like calling a routine in a wodge of machine code). At that address will be constructed an LDR PC, xxx to jump into Basalt.

Another thing to put in mind. If you are going to allow hard linking (a la CLib), what will happen upon *RMKill Basalt?
You have two options. The first is a claim/release tracker so you only quit when you know there are no applications linked, but this suffers from the problem that crashing applications don’t always exit tidily. The second, and perhaps safest, is to keep the jump table in memory forever once Basalt has started (it’ll be small, no big deal) and then upon module exit, patch all of the branches to go to a bit of code that simply returns; or if you have an error flagging mechanism (such as V set), do that. The programs won’t work properly, there’s nothing you can do about that, but you can mitigate against branching into who-knows-what.

Just my ideas. Feel free to ignore… ;-)

Thanks, Rick. Your ideas have been stimulating.

Basalt already uses a fixed block in RMA to vector the primary BASIC entry point through, which makes reloading the module possible. I had not thought of a dynamic area for this, but I do not think it is much different, because it will not have the same address every time the computer is run, in much the same way.

I can see how this could be extended to a branch table, which would deal with the problem for in-line bits of BASIC assembler, but not for saved blocks of code. I could also see a way I could write modules to keep a branch table up to date using a service call, but that is not for the fainthearted.

Now I think I can see a way to combine two branch tables to achieve my end, but it does mean that all pieces of assembled code will have to include one of them, which I did not want to do.

Using SWIs is seductive because it is so straightforward and simple to code and use. ;-)

because it will not have the same address every time the computer is run, in much the same way.

And? We don’t write code like that any more. Not since the BBC Micro. ;-)

but not for saved blocks of code. I could also see a way I could write modules to keep a branch table up to date using a service call, but that is not for the fainthearted.

?

Why not provide a SWI to return the location of the branch table? If the SWI fails, Basalt isn’t loaded (or is an older version that doesn’t do the clever stuff). If it succeeds, then there’s your base address.

I had originally written this:
You could then do branching by LDR Rx, baseaddress followed by something like ADD PC, baseaddress, function, LSL#2 to jump to ((base + (func*4)…

But thinking about it, that’s a pain in the ass for a programmer to remember. Much simpler, perhaps, to specify that a trashable register (can we nick R8?) is used as a function pointer, and then branch to the code address, like:

   MOV   R8, #7   ; Basalt_SomethingFunc
   LDR   PC, basalt_code

and the jump table logic will exist there (akin to a standard SWI jump table). This minimises how much the application writer would need to do to get it working.

Okay, none of this is as sexy as CLib’s embedded jump table, but the fact that you can’t softload a softloaded CLib is a pretty good demonstration of the failings of that method. If you look after the jump table (DA or RMA, doesn’t really matter which) then there should be no problem with transparently “upgrading” Basalt while such programs are running.

Using SWIs is seductive because it is so straightforward and simple to code and use. ;-)

For the lulz, it might be an idea to set up a simulated jump table (get a pointer into your module, jump into it, then jump again) and a SWI. Both simply MOV PC,LR.
Call each a few hundred thousand times, using the Pi’s HAL timer to time how long each method took (to ms accuracy).
Why? Simple. If there isn’t a difference that takes your breath away (like FPE!), then just wimp out and use SWIs. After all, the OS and Desktop use SWI calls all over the place.

So maybe the real life impact will be minor enough that you’ll just use SWIs (‘cos it’s loads simpler)?

Why not provide a SWI to return the location of the branch table?

Yes, I have put my table in the fixed RMA block and have a SWI to return the address. This works fine with runtime code, but not with saved code.

You could then do branching by LDR Rx, baseaddress followed by something like ADD PC, baseaddress, function, LSL#2 to jump to ((base + (func*4)…

That works, and is one of the possible methods to call the BASIC branch routines. However, it requires the use of a register and those are [Edit out: not] generally allocated. It is also inelegant.

specify that a trashable register …

Same problem, I’m afraid.

What I use for my calls is to assemble a block like this:

 .VARIND  LDR pc,[pc,#-4]:EQUD 0
 .STOREA  LDR pc,[pc,#-4]:EQUD 0
 .STSTORE LDR pc,[pc,#-4]:EQUD 0
 ...

Then fill in the actual addresses of the routines in the words after the LDR. Anywhere in the code I can then do, eg: BL VARIND without any further fuss.

It is that sort of table I am now using, but to be useful for saved code the code itself must have a second table and start with a SWI call that fills in the address from the first table that are valid at that runtime.

If your mind is boggling at that, so was mine up until today. ;-)

So maybe the real life impact will be minor enough that you’ll just use SWIs (‘cos it’s loads simpler)?

Your suggestion of finding out just how much overhead there is is a good one and I may yet do that. For now, I must tidy up what I already have.

Thanks.

Your suggestion of finding out just how much overhead there is is a good one and I may yet do that.

Just to round this off, for Rick’s interest if no-one else, I have done some checks.

Using SWIs is about 2 to 3 times slower than using the indirection of branches, which is about 2 to 3 times slower than writing code without branching into the Basalt module. If the routine is a long one, these overheads represents a smaller proportion of the whole.

Using SWIs requires no extra code in a routine. Using branches requires a small piece of initialisation code and a 512 byte table. Writing code without branching requires replication of the routines used, which can be simplified with a library.

For my own purpose the branching is favourite, but if my intention to ease the route into writing code to interact with BASIC is followed, then SWIs are favourite. So, I will probably keep both. ;-)

Will anyone be interested in using it?

Yes, definitively…

Writing code without branching requires replication of the routines used, which can be simplified with a library.

Writing that library, I have yet another question, probably for Jeffrey.

Using the BASIC assembler I want a FN/macro that can preserve a variable number of registers. So I have, for example:

DEFFNRead_Integer(R%)
 R%=R% AND &FE OR &FFFF0000:REM mask registers to only those affected; r0 never
 [OPT F%
 STMFD    r13!,{r1-r7}
 BL       Basic_EXPR
 MOVeq    r0,#28;		type mismatch - number needed
 SWIeq    "Basalt_GenerateError"
 BLmi     Basic_FIX
 LDRB     r10,[r11,#-1];	get last character
 LDMFD    r13!,{r1-r7}
 ]
 P%!-28=P%!-28 AND R%:REM modify register list
 P%!-04=P%!-04 AND R%:REM modify register list
=0

R% is the numerical value for the reglist, but if it is 0 – no registers need to be preserved – that results in a STMFD instruction with 0 in the register field. This seems to work, but what actually happens? It is probably not safe, but I am intrigued. ;-)

R% is the numerical value for the reglist, but if it is 0 – no registers need to be preserved – that results in a STMFD instruction with 0 in the register field. This seems to work, but what actually happens? It is probably not safe, but I am intrigued. ;-)

ARM’s official stance is that LDM/STM with no registers in the list is unpredictable. So it’s probably best to avoid that situation (e.g. have FNpush/FNpop functions that select between LDM/STM, LDR/STR, and nothing depending on the number of registers – IIRC the rule is that on ARMv4+ LDR/STR is quicker than LDM/STM if there’s only one register to transfer)

@David F: Yes, definitively…

That is encouraging, but in what way would you use it?

Here is my take on interacting with BASIC from assembler; it is not about writing assembler to produce fast code to do complex tasks.

Anyone with expertise and the manual can work out how to do it, although there is a handful of pitfalls, and the information is not in a convenient form. There have been very many such experts in the past, but there are probably only a few now.

Here are some limitations that might put newcomers off:

• CALL can only be passed variables as parameters, not values
• Decoding CALL parameters is awkward, being in reverse order
• USR cannot take parameters
• USR can only return an integer value
• The available internal BASIC routines are obscurely named and need careful use
• Calling those routines is not as simple as the manual suggests
• Some useful internal BASIC routines are not officially available
• Error reporting is not straightforward, which has been exacerbated by the removal of BASICTrans from the later versions of RO5

For many years I have been writing code supported by routines that overcome these limitations, and recently I have been thinking about making these available, to encourage others so that they could extend BASIC by machine code as well as PROC/FN. Hence the questions in this topic.

In essence, I use CALL or USR to interpret the program that follows the keyword, using the official BASIC interpreter routines, returning to the program at the appropriate point, and in the case of USR returning a value. This requires manipulation of values on the stack and knowledge of how USR returns values.

The routines I have in mind here hide away the tricky bits and provide a programmer with a simpler interface, at the expense of some overheads, as I have mentioned.

Because these routines already exist in Basalt my strategy is to make them available from there, rather than describe how to write them and include them in assembled code. Documenting the former might be relatively easy, but explaining the latter would not. ;-)

A dilemma is how much overhead to accept in exchange for simplicity, but in the absence of arguments against, SWIs seem best suited.

I will do this anyway, for the personal satisfaction, but I ask again, David, in what way would you use it?

I will do this anyway, for the personal satisfaction, but I ask again, David, in what way would you use it?

To extend the Basic too. For example, I work now for a customer on a mini ERP system.

Done under Windows with BBC Basic. Here, I use Forth for speed critical things, as compression routines.
For RISC OS, a Forth DSL could be done too and will help to make the application more portable.

So basically, for DSLs.
That’s just one idea…

I do not think ARM BBC BASIC is likely to be much use for a DSL as you descibe. Forth, maybe, and there is a RISC OS version, but that is not going to be portable, is it? I envision the use of CALL/USR as I describe as being an alternative to PROC/FN when a programmer wants a particular routine to be faster, but has been put off using assembler before. My guess is that most uses of CALL/USR only pass parameters in the resident integers.

Just reminiscing, I first came across Forth in a version written in Spectrum BASIC! I did go on to experiment with White Lightning, so I understand the speed aspect, and parts of the Spectrum rom were written in Forth.

To extend the Basic too. For example, I work now for a customer on a mini ERP system.

I’m intrigued. ERP stands for:
Emergency Response Procedure, Enterprise Resource Planning, Engine Room Pump or …

I know that as Effective Radiated Power. And the other as Digital Subscriber Line. Hmm.

However, from experience, the French really like acronyms. ;-) It is probably Enterprise Resource Planning. What used to be stock control and human resources (namely making sure the right stuff and the right people were in the right places at the right time) now has a trendy middle-management friendly name…
…and they’re probably the ones responsible for the g****mn JIT meaning that nothing is where it should be when it needs to be. :-/

And I took DSL to be domain specific language, which is why I doubted BASIC was a good starting point. ;-)

I do not think ARM BBC BASIC is likely to be much use for a DSL as you descibe.

My idea is to make a DSL in ASM. But I need ASM code to be able to interact easily with BBC Basic code.
Of course, it will not be portable (and I don’t care, since Forth already exists on BBC Basic for Windows).
I just want the code that will use it to be (more) portable.

Enterprise Resource Planning

Yep

And I took DSL to be domain specific language, which is why I doubted BASIC was a good starting point.

Yes and no. ASM is almost a DSL for BBC Basic.
With BBC4W (another acronym), the ASM DSL is even used to make a Forth DSL :)

My idea is to make a DSL in ASM. But I need ASM code to be able to interact easily with BBC Basic code.

Using BASIC, I think the equivalent to a DSL would be a task-specific BASIC library. From there you could speed up specific routines using assembler, called either within a PROC/FN, or replaced by my proposed syntax – see the example I posted earlier. Those ‘interact easily’, I think. Taken to extremes, you would want something like Basalt, but with task-specific keywords, which might be equivalent to library modules in Python. This is not inconceivable, but BASIC is not simply bent to such purposes.

ASM is almost a DSL for BBC Basic

Really? BASIC is a general purpose language (GPL) and assembler is the ultimate GPL.

Argh! GPL! Argh! :-P

I mean, it’s implemented like a DSL. Language in a language and different uses.