Rick's b.log - entry 2020/09/19

We jump into the library two more times, and finally a branch to &88EC which is the start of our code.

Following this branch, four blocks of code calling OS_GenerateError for the following errors: Failed to initialise workspace, Not enough memory, ABCLib not loaded, and Array subscript out of range.
Then there's the exit handler previously discussed, then the word where the entry R14 is stored, then the word that is our return code. This is followed by a word that is "END" with a null terninator. It appears that this is what is passed to OS_Exit as the error block pointer!

Then follow four error blocks that correspond to the four OS_GenerateError code blocks.

Finally, we have three "useful functions". The first looks like it strips flags from R14 (so 26 bit behaviour) to get an address, the contents of which are loaded into R0. R1 is set to 0. R14 is incremented to point at the next instruction before calling into the library. Looks like something that might be passed to Debugger_Disassemble?

The second routine sets R7-R1 (yes, backwards) to zero, then returns to caller. Perhaps used prior to setting up a SWI? If so, one might want to let them know that SYS accepts values in R8 and R9 these days.

The final routine uses three EOR instructions to swap the contents of R0 and R1, then calls into the library.

Finally, the "ABEX" word used by OS_Exit, and four null words that are replaced by the start of the heap.

 

Looking at a dump of the program post-execution, we can spot some other things.

Many of the words from &800C to &82D0 appear to be unused. I wonder if this is perhaps used as temporary workspace for, say, constructs like PRINT "Result is "+FNtest ?

The words from &830C to &8348 are a base 2 table from 1 to &8000.

The words from &834C to &8388 are a series of values that is like the base 2 table minus one: 1, 3, 7, 15, 31... these are typically used as mask values, like masking a byte is (value AND 255).

The words from &838C to &83C8 is an inverse series of mask values starting from the second nibble.

The words from &83CC to &8650 are all LDR PC,&xxxx as they are the jump points into the ABC library module. With 644 words, there are 161 different routines that could be called.
This is followed, &8654 to &88D8, by a list of addresses used by the jump points. It works in the same manner as SharedCLibrary in using LDR to pick up an address to push directly into PC.

Following that are those two "ARM" strings, and now we have a complete overview of how the program is put together.

 

Yes, that second routine (R7-R1 = 0) is used by SYS calls. I made a test program that made a SYS call, and it was assembled as follows:

BL      &8C1C
MOV     R3, #3
MOV     R2, #2
MOV     R1, #1
MOV     R0, #0
SWI     XOS_CRC
BL      &8934

It calls the function to blank all of the registers, sets up the ones it needs, then directly calls the SWI. The final BL is the one to an empty function. Then we would carry on to set R0 to point to the return code, compare PC with 0, and call the exit routine.

It is worth noting that ABC cannot cope with using registers R8 and R9 in SYS calls. So I hope you never wish to use the following with ABC:

• DeviceFS_CallDevice
• FileCore_* (most of them)
• OS_CallAVector
• OS_DynamicArea 0 (create area) and 2 (area info)
• OS_Hardware
• OS_FSControl 26 (copy) and 28 (count)
• OS_Upcall 3 (file being modified)
• SCSI_* (most of them)

I just tried a simple program to create a DA, and the name was "ÎÿÿÿÎÿÿÿ" because at that point, R8 was pointing at the two &FFFFFFCE words.

Looking at the executable of that, it seems that ABC can be quite literal in its behaviour. On return from the OS_DynamicArea call, I keep a copy of R1 (area number) and R3 (area base address) to report to the user.
Which leads to this:

STR     R1, [R12, #128]  ; store DA number
STR     R3, [R12, #132]  ; store DA base
LDR     R0, [R12, #128]  ; pick up DA number for STR$

It looks like ABC uses the bare minimum of registers which is usually only R0 and R1 and sometimes R2, and it performs all of its behaviour in little chunks that load and save values from/to memory, without context as to what is happening elsewhere, otherwise an optimiser might have noticed that the LDR could be easily replaced by MOV R0, R1.

To put that comment into context, I wrote something similar in C. The first version (using a single printf command) noted that the printf was being called with R0 being a pointer to the string, R1 being the first parameter, and R2 being the second. So the entire output was to ADR the string to R0, and then move R3 into R2 (as R1 happened to be already correctly set up).

I split the printf into pieces to better reflect how BASIC behaves, and in this case the DDE compiler pushed R1 into R4 and R3 into R5. It then ADRed R0 to what was to be printed, retrieved into R1 one of the values in R4 or R5 if necessary, and then called the printf routine. Repeat until it is all printed out. Nothing is loaded nor stored as in this instance the necessary data can be entirely held in registers.

Well, what else to do on a drizzly day? ☺

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

John, 19th September 2020, 21:46

You got drizzle? I should be so lucky, so lucky…

David Pilling, 20th September 2020, 18:29

Mono-spaced in Courier comments. Have you done the usual futile thing of finding out who wrote ABC and asking for the source code. Guess there are a few BBC Basic compilers around.

Rick, 20th September 2020, 20:25

No reason the comments should look different. ;-)  One day, I might get around to writing some PHP that can take snippets of BASIC and output formatted colourised HTML that I can drop into my pages. One day...    There are three BASIC compilers that I know about.    The first, that is easily discounted, is Whizz. It is incomplete. I downloaded a copy ages ago and messed around with it to work on a 32 bit system (it is crunched BASIC). It can compile a number of simple programs, but the output code is *HORRIBLE*. In one case, I noticed it stacking all of the registers FIVE times in a row simply to set a register to 1 and then unstack them all again. Indeed, a program created by Whizz WILL spend the majority of its time stacking and unstacking everything.  This is acceptable in an early incomplete build of a compiler. But, sadly, that's all Whizz is. There's no source, it doesn't ever seem to have been continued, and...    The next compiler is RiscBasic by Silicon Vision. Everybody says it is "as good as BASIC" and supports everything correctly. It last got updated for the StrongARM and then it pretty much vanished into obscurity. I guess the SV guys gave up on RISC OS at that point?    Finally, we have ABC. The current BASIC compiler supplied with the DDE. It has numerous quirks and restrictions (for some people, anything regarding the use of LOCAL is a berserk button) and more importantly it only supports the RISC OS 3.10 dialect of BASIC.  Sources are NDA or something, ROOL has a copy but like much of the DDE they can't be made public.  I have asked. And have been asking and dropping hints for... oh my god... over half a DECADE ago. To be honest, I've lost hope and lost interest.    Which is a shame, because when there's somebody (who already has the DDE) who wants to try to extend the features to cover some more "recent" (as in 1996!) versions of BASIC, such as COLOUR r,g,b and who is willing to do it with respect of the closed nature of the sources AND for free... it seems somewhat silly not to take them up on it.  But, alas, I guess it is somebody's pet and they don't want to let it go. It only recently (as in last year) gained support for understanding hex in lower case or mixed case ... something I noted way back when; but then I'd have been inclined to toss the string at OS_ReadUnsigned or whatever and get the OS to handle it, rather than trying to roll my own hex parser.

Steve Drain, 20th September 2020, 22:03

There is also sBASIC. It is very simple, written in sensible BASIC and outputs BASIC assembler. It was never developed.

Rick, 20th September 2020, 22:38

I've also just found Dan's Tiny BASIC Compiler.  It is extremely rudimentary, not terribly helpful (parser errors usually result in "Missing"), but I still have to commend it.  Why?  Because it's a command line program that looks like it was written for Arthur. Yet not only it but ALSO IT'S OUTPUT work exactly as they should on a 32 bit Pi!  (I haven't tested everything, but what I've tried so far has worked)

Steve Drain, 21st September 2020, 11:56

Just some details for SBASIC:    By Barry Wickett in Acorn User May 1992

Rick, 21st September 2020, 14:10

Just been in touch with Darren regarding Whizz. He no longer has a copy. Something else lost to time. :-(    AU in May 92? I think that's post Yellow Pages isn't it? So I'd need both the magazine and an image of the cover disc. The magazine I can sort - 8bs has scans of them...

Rick, 21st September 2020, 14:17

Nope, the listings are all there. Got a copy from http://8bs.com/aumags.htm, I'll toss the relevant pages to the laser when I get home... ;-)

Steve Drain, 21st September 2020, 16:40

I have an image of the disc, or just the app, if you want it.

Rick, 21st September 2020, 19:46

Sure, a copy of the app would save typing it all in. ;-)    Whoa, that takes me back. Printed out the stuff, plus the reviews of Hearsay 2 and the PC card (I have one of those somewhere) and kind of got stuck reading through all the stuff in the WE adverts and their infamous stripey green/black edged pages. Just like I did countless times way back when...

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 45768 backwards.
		Your comment