BASIC assembler help

Now that the cogs have turned a bit and I’ve spotted my earlier mistake about absolute addressing, the way that you’re handling LDRs and STRs still seems very odd. You’ve got all of your storage locations inside your assembled code, which is unusual. A module would allocate its workspace on the fly, then use offsets into that memory – which explains the indexing through the workspace pointer in R12.

You’re not doing that, although whether you should is a separate question. However, you do seem to be trying to mash the two approaches together, which explains why you’re having so many problems with EQUDs and labels and offsets and stuff.

Since your code opens with

[OPT pass%
  ; Some stuff
  ;
  ; DATA AREA
  .pollword     equd 0    ; offset &08

then any of your code (that falls within +/- 4K of this location) can access it just fine with

LDR r0, pollword

or whatever. The assembler will just turn this into

LDR r0, [pc, #offset]

for you behind the scenes, so it’s as relocatable as anything that you do with R12. As such, there’s no need for you to separately define

REM start of data block, offsets needed
REM note these variable names are used when assembling, not the labels lower down.
pollword%    =8 :REM offset=&08 shared with SocketWatch module

or pass the address of the code in through R0 for storage in R12 and use as a base for data access. The assembler will do a much neater job, whatever the values of O% and P%, if you just do

.label EQUD 0
;
; ... things happen ...
;
LDR r0, label

and leave it to worry about the numbers for you. This is also true of the vector routines and other callbacks: you don’t need to set or read the R12 value, because the assembler still knows how to reference the variable locations to the LDRs and STRs through PC.

ARM assembler has always been relocatable. If your code is less than 4K in size, or 8K if you stick the data block in the middle and not at the head, your code always knows the exact relationship between the instructions and will contain that baked in to a PC-relative LDR or STR.

There are one or two very specific reasons to directly place code in the RMA, but the general advice is DO NOT DO IT.

Druck’s advice is very wise. This code has all the hallmarks of a module, and should be a module.

The reason for using the R12 stuff is that in a module, the data isn’t stored in locations assembled into the code with EQUD and the like. That’s reserved for static constants which never change. The data goes into a workspace, which is allocated at run-time from a separate chunk of RMA. This is what I was trying to get towards above with the FNworkspace_equd() stuff above, which quickly turned very ugly. Again, if you do this properly, it’s trivial.

First, the storage offset values for LDR and STR are set up once, not in the assembler, but outside – often using a workspace allocation function. For example

workspace_size% = 0 : REM Updated as we go...

pollword = FNworkspace(workspace_size%, 4)  : REM pollword = 0
status = FNworkspace(workspace_size%, 4)    : REM status = 4
readtimer = FNworkspace(workspace_size%, 4) : REM readtimer = 8

REM ... and so on...

The definition of FNworkspace() is simple:

DEF FNworkspace(RETURN size%, dim%)
size% += dim%
= dim% - size%

The storage is set up in the module’s init routine. On all module entry points, R12 points to the “module workspace word”, which is a single word in memory that’s initially set to zero by the OS. One word isn’t much, but the convention is that you allocate the actual workspace using OS_Module 6 and then store its address in the workspace word.

After that, the workspace word is largely useless, so again convention is that R12 is immediately updated to point to the actual workspace.

.init
  STMFD r13!, {r14}

; Claim the workspace.

  MOV r0, #6
  MOV r3, #workspace_size%
  SWI "XOS_Module"
  BVS init_exit

; Store the workspace pointer in the workspace word.

  STR r2, [r12]

; Make R12 point to the workspace.

  MOV r12, r2

; Do the remaining initialisation...

.init_exit
  LDMFD r13!, {pc}

Freeing the workspace is the last thing that we do in finalisation.

.final
  STMFD r13!, {r14}

; Get our workspace pointer into R12

  LDR r12, [r12]

; Do the other finalisation...


; Free the workspace.

  TEQ r12, #0
  BEQ final_exit

  MOV R0, #7
  MOV r2, r12
  SWI "XOS_Module"

.final_exit
  LDMFD r13!, {pc}

And that’s it. Whenever you enter a routine through one of the module entry points, you’ll have R12 pointing to the module workspace word. That’s pointing to the pointer to your workspace, so you get to the actual workspace pointer into R12 by

LDR r12, [r12]

as above, and then you can do things like

LDR R0, [r12, #pollword]

with impunity. In callback routines, where you’ve supplied a value for R12, this will usually be the direct pointer to your workspace, as you’ll have done the LDR R12,[R12] bit before setting the callback up (but either way, you control what R12 is in those situations).

Again, this is all nice and simple to understand. The reason things got complicated up-thread is because you’re trying to do some mashup between the two standard ways of working. This seems like a really bad idea.

If you’re assembling the variables into the codespace, such as

.myvar EQUD 0

then use absolute addressing like

LDR R0, myvar

If, on the other hand, the values are in workspace allocated on the fly, such as in a module, then index through R12. Don’t mix the two. If your code gets bigger than the +/- 4K limit for absolute addressing, use the workspace approach that supports up to +/- 4K of workspace, not distance distance between the LDR and the value that it’s loading.

That said, there’s a reason why we use higher level languages these days.

This code has all the hallmarks of a module, and should be a module.

I concur. This should be written from the ground up as a module that can be installed and de-installed as the user desires.

You have Steve’s explanation above.
You have my original module (written in assembler).
And, if it helps, there’s this: https://heyrick.eu/blog/index.php?diary=20171003

there’s a reason why we use higher level languages these days.

So very much this.
As I kept saying to DavidS, the problem with assembler is that while it offers raw power and the ability to get things done by directly talking the language of the processor, it also saddles you with a lot of annoying grunt work that you really shouldn’t have to bother with.
All this confusion over which method of addressing to get a value into a register… why? This is why mankind invented compilers – so we can express what we’d like the code to do and let the compiler worry about the how part.

If you have the DDE, then it’s not hard to write a module in C.
Example: https://heyrick.eu/blog/index.php?diary=20150323

The only reason I didn’t write my module in C in the beginning was two reasons:
Firstly, since the original code to talk to the PIC was thrown together using BASIC’s assembler, I just copied the code over (I find ObjAsm code easier to read, and fewer gotchas like P% or OPT or the ‘:’ issue).
And secondly, because I was concerned as to the impact of using C given that when filing operations happen, they happen a lot. This is, of course, mostly an imaginary concern born of the days when the processor ran at 8MHz and instruction sequences could be timed to the microsecond. I keep trying to tell myself that the USB subsystem can splatter thousands of events per second, and from time to time Jon posts information on ADFFS aborts-caught which are insanely large numbers. So I will have to wean myself off of this way of thinking, suffice to say that sometimes just putting together a little dodah in assembler can be as simple for me as writing one in C…

But, yes, high level languages are good because the compiler worries about the specifics of how the processor works, leaving you to worry about calling your vector releases in the right order. ;-)

Like Steve, my cogs have turned a little. Following on from him saying…

the allocation seems to be assuming way too much about how BASIC allocates its storage

the following code snippet illustrates why writing to BASIC memory can so easily be very dangerous:

1 DIM mm1% 3, mm2% 3  :REM Allocates 4 bytes
2 !mm1% = &31313131   :REM Set to "1111"
3 !mm2% = &32323232   :REM Set to "2222"
4 *Report ~(!&85b4) "Start of m variable list"
5 *ReportDump ~(LOMEM) (END-TOP)
6 *ReportMem V  A
7 $mm1% = STRING$(4,"x")
8 *ReportDump ~(LOMEM) (END-TOP)
9 *ReportMem V A

~(!&85b4)=&9028 Start of m variable list
Memory Dump From ~(LOMEM)=&9028  Length (END-TOP)=32
    9028 ¦38 90 00 00·6D 31 25 00|34 90 00 00·31 31 31 31 : 8‘..m1%.4‘..1111 : +0 
    9038 ¦00 00 00 00·6D 32 25 00|44 90 00 00·32 32 32 32 : ....m2%.D‘..2222 : +16 
Memory: Prog=296 Vars=32 Free=5,115,792 Stack=40 Undefined=0 Slot=5000K 
PAGE=&8F00 TOP=&9028 LOMEM=&9028 END=&9048 r13=&4E9FD8 HIMEM=&4EA000 MEMLIMIT=&4EA000
Memory Dump From ~(LOMEM)=&9028  Length (END-TOP)=32
    9028 ¦38 90 00 00·6D 31 25 00|34 90 00 00·78 78 78 78 : 8‘..m1%.4‘..xxxx : +0 
    9038 ¦0D 00 00 00·6D 32 25 00|44 90 00 00·32 32 32 32 : ....m2%.D‘..2222 : +16 
Memory: Prog=296 Vars=32 Free=5,115,792 Stack=40 Undefined=0 Slot=5000K 
PAGE=&8F00 TOP=&9028 LOMEM=&9028 END=&9048 r13=&4E9FD8 HIMEM=&4EA000 MEMLIMIT=&4EA000
&9038 mm2%             BadPtr=&D
10:31:45.27 ** Error **
  Error  : &00000000
  Message: ReportMem: BASIC lists have Bad Pointer(s)

Line 7 writes a 4-byte string to mm1%, which sounds reasonable as 4 bytes were allocated.
However, the second Memory Dump shows it also writes a trailing &D (carriage return) at &9038 which has overwritten the address in the next variable entry. This is then picked up by the validation – but if allowed to continue some nasty error could happen at any time – eg a mm3%=999 would provoke a Data Abort in BASIC.

With just 2 variables used, there are 4 addresses within the variable memory, imagine how many there are with hundreds of variables. If ANY of these are corrupted, trouble will approach. In my experience, weird happenings in a BASIC program are usually caused by the program corrupting memory. Anything which writes directly to memory is suspect – including indirection operators !?$, and assembling code. The tricky bit is finding where … which is why I added list validation to Reporter.

1 DIM mm1% 3, mm2% 3 :REM Allocates 4 bytes

Ah, but the majority of code you’ll see (<cough> including some of mine </cough>) writes the numbers as if counting from 1, not zero. ;-)

7 $mm1% = STRING$(4,“x”)

The gotcha here is not that you’re overwriting the memory by accident so much as BASIC always terminates strings with no way to disable this behaviour. You can in PRINT by using ‘;’ at the end, but in the above example, it’s always terminated.

Something to watch out for in data blocks that expect to be null terminated, if you set the variable as $block% = some_string$+CHR$(0) then you need to be aware that you will be terminating twice. The null byte that you have specified, and the carriage return byte that BASIC insists on adding. So always ensure that there is room for the terminator.
[of course, DIM block% 4 is an easy hack as that would allocate 5 bytes, so the above would then work ;-)]

@Rick: Agreed – it was just a minimal program to illustrate that consecutive DIMs do not allocate consecutive memory blocks – there are many pitfalls which may be hidden.

DIM block% 4 is an easy hack as that would allocate 8 bytes, so the above would then work

Corrected that for you. ;-)

Thanks guys. Lots of good stuff to think about there.

It is probaby worth explaining why I made some of the decisions I did, even if those turn out not to be good reasons.

1 It’s in BASIC assembler because I don’t have the DDE and objasm, and it won’t work in BASIC alone.

2 The original design flashes an icon on the iconbar. That’s done in the BASIC program, triggered by the pollword. That bit has been working for quite a while. So it is designed as an application, with an assistant in assembler.

3 The code is in RMA because it needs to run under interrupts, and can’t do that in application space which gets paged out. Is there somewhere else i should put it?

4 The reason I use BASIC variables to point into the data space is so that the BASIC program can access what the assembler has done. That’s proved useful in debugging the assembler.

5 The reason for the fiddling about with &10000 was to try and put the code on an easily readable boundary, making checking address offsets easier when reading the listing. The original version assembled directly into an RMA block, and this “simplification” seems to have produced some of the problems. That’s easily fixed.

6 The reason for not making it a module is that I don’t feel comfortable with that, particularly as I can’t see how to debug one. I also don’t know how much Wimp stuff can be done within a module. It feels to me, possible erroneously, that Wimp stuff is for applications.

The original design concept changed once I realised that the flasher stopped working during a lot of things that I wanted an indication of, such as large *copy operations. That lead to two additional features being planned – one to use the pointer colours, and the other on the ARMX6 to add hardware to flash the existing unconnected front-panel LED. Both of these need to be done in a callback routine it turns out, and it was adding that, that started to show up some of these problems.

So it’s evolved away from a fairly simple design, as these things tend to do. I’m going to have to think about some redesigning, although I’m not yet convinced that it will become a module.

By using Basic$Crunch to hide some of the issues I’ve got code that runs, doesn’t crash the machine, and does change some of the pointer colours, although not correctly. So it’s close, and I don’t want to go too far backwards in order to go forwards.

A start will be to ensure I assemble into a single DIMmed area with no embedded variables – I had forgotten about that one. Separating out the data space will need a bit more work.

As it’s a nice day, I think I’m going out on the bike first to clear my head a bit.

3 the RMA is the correct place, but it should be wrapped as module, for the advantages given above
5 its even easier if you make the code a relocatable module as you compile to target address 0
6 you debug a module the same ways as you do now, you can do anything in a module even making it a full wimp task

you debug a module the same ways as you do now, you can do anything in a module even making it a full wimp task

For some reason I couldn’t get my head around the idea of a Wimp_Poll in a module.

Debugging at the moment relies on the BASIC part of the system – the assembler stores a couple of values in some spare locations, whose address is known to BASIC. The BASIC part uses these to do things like *reportmem using the addresses it’s just found. That’s one reason for having BASIC variables containing offsets into the code block, or more accurately into the data that’s currently part of the code block.

Every time a significant event occurs the pollword is changed. Part of the BASIC that responds to that dumps some data out using the mechanism above. It means I see a sequence of things happening as the lights go off and on. The bit with the iconbar lights does work.

One reason for fiddling around with the address of the block was for using *memoryI with a base address I could remember, and easily add offsets to. It’s just I got the creation of it wrong.

My thought at the moment is to finish debugging the callback code this way, as it’s nearly there. Then think about changing the memory layout, and then see if I can understand how a module works. Steve’s version should help me with that bit.

The good thing for this fun(?) activity, is that I discovered that an event I had coming up, that would have put some pressure on my time, has been cancelled for the usual reasons.

consecutive DIMs do not allocate consecutive memory blocks

Indeed. The danger of assumptions. :-)

Corrected that for you. ;-)

Thanks. I should have said at least 5 bytes. Didn’t want to confuse the matter with word alignment.

1 It’s in BASIC assembler because I don’t have the DDE and objasm,

Fair enough.

3 The code is in RMA because it needs to run under interrupts,

So, should be a module. ;-)

If you want to keep your BASIC front-end, then simply get your shiny new module to set a word somewhere to 0 (no LEDs), and then 1-3 depending on which bits you want to mean “read” or “write”.
When an event happens, set the word accordingly and, if necessary, schedule a CallAfter to clear the word.
If you’re only setting/clearing a word then it can be done directly. If you’re also setting pointer colours, that’ll need to be done on a callback.

Then, provide a SWI that returns the address of this word. Your front-end can read this address, and then pass it to Wimp_Poll(Idle) as a PollWord. When the Wimp notices this word is non-zero, you’ll get polled with event PollWord_NonZero. It provides the value of the word for you, so you can act upon it directly.

6 The reason for not making it a module is that I don’t feel comfortable with that, particularly as I can’t see how to debug one.

Carefully. ;-)

It’s not RISC OS’ strong suit, especially when you’re in a privileged mode and any little whoopsie with stacking/unstacking will likely stiff the machine.
But, then again, when you’re responding to events and vectors, it’s exactly the same situation, so it being in a module (or not) doesn’t change an awful lot.

I also don’t know how much Wimp stuff can be done within a module. It feels to me, possible erroneously, that Wimp stuff is for applications.

There are four ways of accessing code in modules.
By far the most common is the SWI interface. Call a SWI, your module’s SWI handler is entered (in SVC mode) with a code representing which SWI was asked for.
The next is the *command. When invoked, your handler for the relevant command is called in SVC mode with the command tail. (in C, it’s a little different and has a command code similar to how SWIs work, it’s an implementation detail)
Next is the ServiceCall. You can register ServiceCalls you are interested in (RISC OS 4 and later), and you must check as quickly as possible to pass the call on if it’s not a call you are wanting to know about (all versions of RISC OS). You’ll be in a privileged mode, RISC OS will be threaded, there’s a lot you cannot do (like no touching the VDU drivers or the OS will blow up).

Finally, there is the Run entry. This is akin to the BBC MOS idea of “entering the module as a language”. You are entered in User mode. You do not return until you’re done. While originally intended to allow you to write full screen applications as a module (as was actually recommended in the Arthur 1.2 PRM!), there’s no reason why you cannot call Wimp_Initialise and start yourself up as a task. Pretty much the only difference between that and a normal task is that you won’t have any slot that gets paged in and out (except under C, but that’s an implementation issue) as your workspace will be in the RMA (except C…).

If you open up Task Manager and look at the list of current tasks, below that it’ll say “Module tasks” and these are ones that are built into modules. Like “Free” and “Filer”.

The original design concept changed once I realised that the flasher stopped working during a lot of things that I wanted an indication of, such as large *copy operations.

Do you not use FilerAction to do it multitasking?

Both of these need to be done in a callback routine it turns out, and it was adding that, that started to show up some of these problems.

Because by now you needed to save state somewhere between the event happening and the callback dealing with it.

As it’s a nice day, I think I’m going out on the bike first to clear my head a bit.

I’ve been out in the garden. Started light, rotovating ground again for my new potato patch. Then took a breather with planting some flowers. And finally sated my inner moppet by levelling the ground where the pine tree used to be (it fell in a storm about a decade ago). This involved a shovel and a pickaxe. Which was… actually quite gratifying.

I’ve just eaten a pack of long-life croissants which were about as awful as you can imagine them to be, but I’m hungry (haven’t eaten yet today, was… busy…) and wanted to sit out in the sun (as I’m doing to write this) and not faff around in the kitchen. I’ll go in soon, it’s starting to get chilly.

Thanks Rick, helpful as ever.

Do you not use FilerAction to do it multitasking?

I do, but some things on my various computers don’t. For example my big BASIC system backs up its database by using *copy to save the files to a different computer. It does them one per wimp_poll so the server can still respond to its other clients, but it would still be nice to see the activity flagged.

Because by now you needed to save state somewhere between the event happening and the callback dealing with it.

Which brings me to the current debugging challenge. When an event needs processing an identical flag value is stored in two places. One is the pollword, and the BASIC part acts on this correctly. The other is used by the callback, and for some reason seems to have a different value by the time the callback runs. It’s not as simple as the sequencing of these I don’t think, because it’s not a lag of one event between them either way. The pollword typically goes 0, 2, 0 for a read, while the callback seems to see 0, 3, 3. Added to this I don’t think it’s changing more than one of the three colours associated with the pointer, or it’s changing them to the wrong values. I suspect I can improve that code using LDM/STM operations, a bit like the Z80’s LDIR instruction. It’s essentially copying 12 bytes from one memory area to another.

As it’s a nice day

until I got on the bike, when the clouds came over and the air started to get very damp – not quite Scotch mist, but getting there.

This involved a shovel and a pickaxe. Which was… actually quite gratifying.

and tenderising for the hands, unless you already have a degree of callousing.
I used to spend my Sunday mornings clearing silted up ditches in the local wood, along with some chainsaw work etc. Callouses like a middle-ages farmer.

The reason for not making it a module is … particularly as I can’t see how to debug one.

Debugging asembler, even if in a module, is perfectly possible with Reporter. You should see the vast amount of debugging info I can get when debugging Reporter! (I do use two Reporters – one to debug and one to report). Otrher methods are available.

And as others have said, a module can certainly be be a Wimp task – indeed, currently I have more module tasks running than application ones!

I did discover an oddity in that commenting out a function reference with either or both of REM and ; does nothing – the function is still assembled.
Both REM and ; comment an assembled line up to the next colon or the end of the line – see the following code snippet:

I left that post unchallenged until today. However yesterday I had the same thing again.

Within the assembler section I had a function reference. That function referenced another function, which assembled code inline (i.e. the code was not set up as a subroutine, but more like a macro). The code in that second function was causing a crash. I added a ; before the FNcrashmachine reference. The next time the code was assembled, the machine crashed.

I then deleted the FNcrashmachine function reference. The assembled code didn’t crash.

On previous occasions I’ve tried using REM as well with the same result.

I think Steve’s put his finger on the reason – you run with Basic$Crunch set, and I do not. That will remove the commented code before the assembler sees it.

you run with Basic$Crunch set, and I do not.

Curious. It’s more efficient to run with it set and costs nothing at all in the readability of the original code.

There was some debate a while back with the view that the system default should be to set it.

I’ve been back to Steve Fryatt’s detailed explanation several times. This time round with a really strong cup of coffee.

The storage is set up in the module’s init routine. On all module entry points, R12 points to the “module workspace word”, which is a single word in memory that’s initially set to zero by the OS. One word isn’t much, but the convention is that you allocate the actual workspace using OS_Module 6 and then store its address in the workspace word.

I had to spend about ten minutes re-reading this bit before I twigged. I think this and the following section is saying that R12 in a module entry is the address of the address of the workspace, not the plain address of the workspace. It’s this sort of thing that’s made me shy of getting into module code.

What made me realise was when he said the address of the workspace should be stored there, and I wondered why it was being stored at address zero.

R12 in a module entry is the address of the address of the workspace

Yes and no … R12 is the address of a Private Word for your module. If you only want to use one word for ‘data’ then that is it. Normally though you need to hold more data, so memory is obtained elsewhere, and you use your Private Word to hold that address (which is the case you gave).

Apologies for resurrecting an old thread — but I hit a snag with the code in Steve’s post at https://www.riscosopen.org/forum/forums/11/topics/16298?page=3#posts-119636

DEF FNworkspace(RETURN size%, dim%)
size% += dim%
= dim% - size%

There’s an error here, if you allocate 4 bytes then 64, the second allocation will get address &FFFFFFFC, when it should get address 4.

The correct code is:

DEF FNworkspace(RETURN size%, dim%)
size% += dim%
= size% - dim%

But thanks for the idea, Steve! It’s tidied up my BASIC Assembler code a fair bit.