BASIC assembler help

was using BASIC functions to try and make the assembler more readable

You were using the correct OPT number before every chunk of assembler?

You were using the correct OPT number before every chunk of assembler?

The main loop and every function each start [OPT pass%. The loop is FOR pass% = 8 TO 11 STEP 3.
Nothing anywhere alters pass%. I hope that’s right?

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.

it would have cost almost as much to buy as the computer did, that wasn’t reasonable.
I don’t know whether it’s changed, but at the time C was regarded as a “write-only language” because it was completely unreadable.

Ah, yes. I recall how utterly expensive Desktop C was. When I bought my A5000 (guy wanted to sell it to get a first issue RiscPC I think), I thought the price was a little high so I haggled and got some bundled software. Some games that I sucked at, some version of Impression that I didn’t like (sorry, Ovation clicked with my way of thinking, Impression didn’t (plus in those days it was kind of fugly)), and the C stuff with all the manuals. Win! ;-)

I think in those days, too, there would have been a lot of K&R style C. Which is a bit of a mess. It probably doesn’t help that C is flexible to the point of becoming gibberish by intent (Google the obfuscated C contest). But once you become more familiar with it, it starts to make sense.

Now, Lua, that’s a write-only pile of punctuation symbols. <poke><poke> Hello Gavin!

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.

It’s not something as simple as the fact that comments in the assembler block are : delimited, unlike in the rest of BASIC?

I don’t know whether it’s changed, but at the time C was regarded as a “write-only language” because it was completely unreadable. Another reason why I stuck with BASIC.

It’s quite possible for BASIC to be “write-only”, too. It’s down to how the code is written, not the language (and BASIC, with its lack of self-documenting structures, is pretty grim once you have a fair-sized Wimp application).

and BASIC, with its lack of self-documenting structures, is pretty grim once you have a fair-sized Wimp application

I think you would agree that the transparency/opaqueness is largely down to the habits of the code author – which you covered in this:

It’s down to how the code is written,

It might be interesting to see a language where the bad/opaque code writing isn’t possible, but I don’t think one exists at present.

It might be interesting to see a language where the bad/opaque code writing isn’t possible, but I don’t think one exists at present.

Wasn’t that part of the rationale behind ADA. (Where “Hello World” compiled to 5 pages of code.)

It’s not something as simple as the fact that comments in the assembler block are : delimited, unlike in the rest of BASIC?

I might be misunderstanding here, but when I put a : in a comment, the bit after was reported as “unknown operand”. Surely comments begin ; ?

in this case the following all get assembled:

; FNtest
REM FNtest
; REM FNtest
REM ; FNtest

I might be misunderstanding here, but when I put a : in a comment, the bit after was reported as “unknown operand”. Surely comments begin ; ?

When you put a : into it the BASIC interpreter sees it as the start of a new command as much so as if you’d hit the enter key for a new line and then typed the remainder of the text.

Suffice to say BASIC assembler != objasm

When you put a : into it the BASIC interpreter sees it as the start of a new command as much so as if you’d hit the enter key for a new line and then typed the remainder of the text.

But not in the context that I gave. A REM comment runs until the end of the line, so

REM This is a comment : and this is also a comment.

However, that’s not the case in the assembler. There, both REM and ; are terminated by :, so

[
  REM This is a comment : but this is NOT a comment.
  ; This is also a comment : and this is also NOT a comment.
]

If you’re a fan of multi-line statements, then the following might (or might not) have a surprise in store:

REM ADR RO, my_data% : LDR R1,[R0]

Suffice to say BASIC assembler != objasm

The comparison that I was making was between BASIC and the BASIC Assembler, which has long been a trap for the unwary.

PS. IIRC, and off the top of my head, this is why the BASIC assembler will accept both tokens and untokenised text for its instructions. ORR might be <OR>R in most cases, but if it follows a REM in a previous statement on the line, it could also be plain ORR as the tokeniser ignores anything from REM to line end.

Now, Lua, that’s a write-only pile of punctuation symbols. Hello Gavin!

As Steve says, it is down to how it is written. I have just put here a small and probably unnecessary application Multisave . As Druck said, an edge case , for when you want to save stuff to lots of directories simultaneously. It is written more for annotation than for use. The program is written as four chunks, each commented for what variables it consumes ( uses ) and what it provides ( exports ). The catch is that you have to read the last chunk first to understand what is happening, because Lua’s operational semantics demand that definitions precede use.

It certainly looks as if the syntax of BASIC and that of the BASIC Assembler were not designed together. Perhaps designed is not the mot juste in this case. The idea of combining two languages, one low-level the other higher-level, is brilliant, however. Lua and C is another such pairing.

I am not sure that the goal of having a really readable programming language is such a good one. It has so often been a trap. Expressivity and readability often pull in opposite directions.

Sorry, but I cannot let these two earlier statements go unchallenged, as surely they are both wrong…

It seems the assembler will use a BASIC variable ending % and strip the % before using it, if that makes sense, so labels and BASIC variables should not have names differing only by the %.

BASIC variables xxx and xxx% are different – see the following code snippet:

var1%= 123
var2 = 456
DIM P% 200
[
.var1  EQUS "xxxx"  
.var2% EQUS "xxxx"  
]
PRINT var1 var1%
PRINT var2 var2%

9000 78787878 .var1     EQUS "xxxx"   
9004 78787878 .var2%    EQUS "xxxx"   
     36864       123
       456     36868

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:

DIM P% 200
[
EQUS "xxxx"     ; start
FNtest          ; test 1
;FNtest         ; test 2
REMFNtest       ; test 3
;REMFNtest      ; test 4
REM;FNtest      ; test 5
EQUS "END "     ; end
]

9064 78787878    EQUS "xxxx"    ; start
9068          
9068 74736574    EQUS "test" 
906C             FNtest         ; test 1
906C             ;FNtest        ; test 2
906C             REMFNtest      ; test 3
906C             ;REMFNtest     ; test 4
906C             REM;FNtest     ; test 5
906C 20444E45    EQUS "END "    ; end

Here’s just little more to add to the assembler comment gotchas.

If you have Basic$Crunch set, then a REM and the rest of the line are removed, and Steve F’s

REM ADR RO, my_data% : LDR R1,[R0]

gotcha will disappear.

The colon for the next instruction can be in a string , so beware commenting out something like this:

;TEQ r0,#ASC":"     ; is character a colon

Fun, isn’t it. ;-)

Wasn’t that part of the rationale behind ADA. (Where “Hello World” compiled to 5 pages of code.)

“Hello World” in Ada is reasonably compact, mostly consisting of the usual ceremony to import the standard lib to print a string.

It depends who you ask, but the Ada rationale includes various different goals:

• please the Pascal fans (no curly braces, begin-end all the way, and of course := for assignment)
• please the power user (because Ada 95 already included everything and the kitchen sink regarding features)
• make it very hard to shoot yourself into the foot
• still allow you to shoot yourself into the foot, but make the danger very obvious
• provide the largest standard library ever seen (only true until probably Java 1.2)
• provide a very complete standardization document
• make it very hard for compiler writers, but easy for developers using those compilers
• establish a comprehensive compiler validation process to ensure high quality compilers (see: ACATS)
• provide rich semantics to allow the compiler and runtime to check things thoroughly

In some ways, it could be said that Ada is the complete opposite of BBC BASIC.

So I’m still fighting the assembler. I got the code to assemble, and run without crashing the machine. Now I’m debugging the program logic, which is not quite right.

AS I make minor changes, which are still valid code I apparently randomly get
“Variable not known” messages on the second pass. These variables can be either BASIC variables defined before the assembly loop, or labels within the code.

For the unknown BASIC variables I added some *report commands here:

status%=16
P%=address% where address% was a DIMmed area more than big enough
FOR pass%=8TO11STEP3
 *report status% pass%
[OPT pass%
...
lots of code
]
NEXT

EDIT I just tried with Basic$crunch = 1, and the access violation disappeared, and it compiled correctly.

So that’s pasted over the problem for now. Steve’s example comment is one I would not have thought of, so it gives me something to look for.

On the topic of why there is no one language to rule them all, I recommend this video .

P%=address%
FOR pass%=8TO11STEP3

P% must be set to address% inside the FOR…NEXT loop. Otherwise your code is being assembled at the value of P% after the first pass. This is writing over the top of heap objects, such as the variables that are going missing. There will be other consequences.

I’ve put the program, as it will demonstrate the Assembler problem, here http://www.adamshome.org.uk/RiscOS/Assembler_Test.zip

It’s a zip file containing enough to attempt to assemble the code, and text file describing what does and doesn’t allow it to work.

It fails without Basic$crunch on both RO5.28 and 5.29 (ARMX6). It works with Basic$crunch = 1 on both.

Minor changes to a *report command can change the faulty behaviour from Access Violation to Undefined Variable.

I’m baffled.

P% must be set to address% inside the FOR…NEXT loop.

I’ve just checked. It is set inside the loop. I made a mistake typing in the example.

this is why the BASIC assembler will accept both tokens and untokenised text for its instructions. ORR might be <OR>R in most cases, but if it follows a REM in a previous statement on the line, it could also be plain ORR as the tokeniser ignores anything from REM to line end.

I suspect this might be part of my problem. I’ve typed all the opcodes in uppercase. StrongED is highlighting AND and OR as keywords, along with a few others, and rather annoyingly it is converting some words typed in lowercase into uppercase and making them keywords too. Mostly (only?) that is occurring in comments though.

Would Basic$Crunch fix the AND / OR keywords issue?

I’ve stopped for tonight. I think I’ll start tomorrow by lowercasing the code and see if it makes a difference.

I think I’ll start tomorrow by lowercasing the code

That would be strange if so… I’ve always written assembler in upper case.

I’ve put the program, as it will demonstrate the Assembler problem,

What’s the logic behind claiming the memory for assembling into? You set size% to 3000, but then DIM marker% &10000. After that, there’s the odd alignment of codespace%.

If you look at the assembly, it starts at &20000 and finishes the first pass at &20540. However, checking the memory allocation in Reporter tells me that

marker%    = &10514
codespace% = &20000
marker2%   = &20528
guard%     = &20550
marker3%   = &2111C

I think that means that you’re running off the end of your first block of memory (at marker%), and since the additional block (at guard%) isn’t contiguous with it, you’ve just blatted over some other information in BASIC’s workspace that it was likely quite fond of.

To be honest, I’m not quite sure why you can’t replace

DIM marker% &10000
DIM marker2% 0
codespace% = ((marker% + &FFFF) DIV &10000) * &10000
IF codespace% + size% > marker2% THEN
  DIM guard% size%, marker3% 0
ENDIF

with the slightly clearer

DIM codespace% size%

The stuff about “extending” the allocation seems to be assuming way too much about how BASIC allocates its storage – not least because you’re creating variables in between the various DIM statements.

If what you’re trying to do is to assemble the code to be loaded and run later on at &10000, then do that using offset assembly:

FOR pass% = 12 TO 15 STEP 3
  P% = &10000
  O% = address%
  L% = address% + size%

However, I suspect that you would be better ensuring that your code is relocatable.

I think I’ll start tomorrow by lowercasing the code and see if it makes a difference.

I think that all of your problems (the crashes, lost variables, % suffixes being “optional” on label variables, dubious macro handling… the lot) are very likely down to the fact that your code would appear to be trampling BASIC’s memory as it goes. The list of problems that you’ve given in this thread are far, far too serious for them to have survived unnoticed up to now, but all shout “memory corruption” very loudly indeed.

Edit: Steve beat me to it! codespace% is certainly the root of a lot of problems. As Steve says, fix that and most (all?) of your strange happenings will vanish.

Indeed, using *ReportMem V validates all the 121 BASIC lists to check the pointers are valid – and it gives

Memory: Prog=28,681 Vars=72,388 Free=1,992,152 Stack=88 Undefined=0 Slot=2048K 
&2052C cL ƒå?? áä      BadPtr=&E7902224
&20518 m?              BadPtr=&E5832044
23:26:45.73 ** Error **
  Message: ReportMem: BASIC lists have Bad Pointer(s)

PS… I’ve just realised that this could screw up your setting of ADDR% and referencing it in the assembled code. You probably want to do

ADDR% = &10000

instead of setting to the address at which the code is being assembled, but again – ARM code allows you to make your code independent of location very easily indeed.

You should not need to bake fixed addresses into your code like this. At the start of the code, you seem to be creating a bunch of labels to actual addresses and then duplicating them as a collection of fixed offsets in the integer counterparts of the variables. Is there any reason for not deleting

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
status%     =12 :REM bit 0 read active, bit 1 write active
readtimer%  =16 :REM countdown timer for read indicator
writetimer% =20 :REM countdown timer for write indicator
countrate%  =24 :REM value to load into countdown timers when starting them
actionflags%=28 :REM do we do hourglass or hardware bits?
savestatus% =32 :REM status copied here before callback, in csse it gets changed
callbackpending% = 36 :REM indicated a callback has already been requensed, don't register another
countcallbacks% = 40 :REM incremented by each callback

and then replacing the initial block of EQUDs with something like

[OPT pass%
  .data_start
  ;
  ; jump table for BASIC entry
  ;
  b  initentry     ; offset=&00 initialisation routine
  b  finishentry   ; tidy up
  ;
  ; DATA AREA
]
pollword      = FNworkspace_equd(data_start, 0)  : REM shared with SocketWatch module
status        = FNworkspace_equd(data_start, 0)  : REM bit 0 read active, bit 1 write active
readtimer     = FNworkspace_equd(data_start, 0)  : REM countdown timer for read indicator
writetimer    = FNworkspace_equd(data_start, 0)  : REM countdown timer for write indicator
countdown     = FNworkspace_equd(data_start, 60) : REM default value FOR timers
actflags      = FNworkspace_equd(data_start, 3)  : REM bit 0 use iconbar, bit 1 use hourglass, bit 2 use hardware
savestat      = FNworkspace_equd(data_start, 0)  : REM status copied here before callback, in csse it gets changed
callpend      = FNworkspace_equd(data_start, 0)  : REM flag FOR callback waiting TO occur
callbackcount = FNworkspace_equd(data_start, 0)  : REM 40dec, debugging counter of callback entries.
save_mode     = FNworkspace_equd(data_start, 0)
save_R14      = FNworkspace_equd(data_start, 0)
[ OPT pass%
  ;
  ; CALL here with R0 set to address%, R1 set to cSec timer values for countdown timers
  ;

You would need to change a couple of

LDR Rn,save_mode

and similar with

LDR Rn,[R12, #save_mode]

but you’re doing that everywhere else anyway.

FNworkspace_equd() is defined as

DEF FNworkspace_equd(base%, value%)
LOCAL address%

[OPT pass%
.address% EQUD value%
]
=address% - base%

All untested, as I can’t easily run the code. It feels like a much more conventional way to do things, though. Multiple sets of variables pointing into the same thing will always come back to bite later on.

PPS. It would be better still to make that opening block something like

[OPT pass%
  .code_start
  ;
  ; jump table for BASIC entry
  ;
  b  initentry     ; offset=&00 initialisation routine
  b  finishentry   ; tidy up
  ;
  ; DATA AREA
  .data_start
]
pollword      = FNworkspace_equd(data_start, 0)

and then initialise R12 in FNinit as follows

; Remember our workspace pointer
ADD      R12, R0, #data_start - code_start ; R12 now points directly TO our data

Again, just personal preference, but then R12 does, indeed, point to the start of your variable storage. I’ve had a very cursory look at where R12 is used, but may have missed something that this breaks.

Hm. I should probably stop thinking about this, but there’s something else rather disturbing about your code.

Edit 20-03-2001: On reflection, this isn’t quite true. It’s certainly confusing, but my concerns about the use of absolute addressing were wrong. However, the point about making life much harder for yourself stands – in fact, it’s even more true.

If I’ve understood the comments in FNinit correctly, you’re assembling this to a file, then allocating a block of memory in RMA and loading it in to that. If so, you’re making life much harder for yourself than it needs to be.

If I’m correct, then forget all of the stuff in the previous post about FNworkspace_equd(). ARM code is relocatable, and it has to be if you’re proposing to load this into a block of RAM allocated on the fly. So do your assembly as if you were writing a relocatable module:

FOR pass% = 12 TO 15 STEP 3
  P% = 0
  O% = address%
  L% = address% + size%

Now, you can return to your opening code of

[OPT pass%
  ;
  ; jump table for BASIC entry
  ;
  b  initentry     ; offset=&00 initialisation routine
  b  finishentry   ; tidy up
  ;
  ; DATA AREA
  .pollword     equd 0    ; offset &08
  .status       equd 0    ; offset &0C
  .readtimer    equd 0    ; offset &10
  .writetimer   equd 0    ; offset &14
  .countdown    equd 60   ; offset &18, default value FOR timers
  .actflags     equd 3    ; offset &1b, bit 0 use iconbar, bit 1 use hourglass, bit 2 use hardware
  .savestat     equd 0    ; offset &20
  .callpend     equd 0    ; offset &24, flag FOR callback waiting TO occur
  .callbackcount equd 0   ; offset &28, 40dec, debugging counter of callback entries.
  .save_mode    equd 0
  .save_R14     equd 0
  ;
  ; CALL here with R0 set to address%, R1 set to cSec timer values for countdown timers
  ;

because all of the labels will be offsets from the target assembly address of zero. You can also return to doing

  ; Remember our workspace pointer
  MOV      R12, R0                     ; R12 now points directly TO our memory

because offsetting R12 by 8 bytes into the code block will be a lot of hassle for limited reward, as it stops you using the “offset into code” effect of P% = 0.

Edit 20-03-2001: The bit which followed about needing to index all LDRs and STRs through R12 was complete garbage; it’s clearly been a while since I’ve written any ARM code that didn’t reside in a module. However, it does lead to a different observation, which I’ll stick in a follow-up post to keep things separate.

A better approach might be to allocate the workspace separately through OS_Module, and pass the address in to this code so that R12 can be pointed to it. Then you pull all of the EQUD’s out of the assembly and do a conventional module-style workspace offset label allocation.

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

Code in the RMA should be in the form of a module; so it can be loaded and initialised on demand, is visible to the user explaining a clear purpose, and removable when no longer required.