Basic ERL after an Abort

Have you ever been infuriated when a program gives an Abort on Data Transfer and a Basic error line … only to discover that it just refers to the last line of the program? If so, please read on…

The Problem

There is a significant problem with Basic when external code is called using CALL, USR, SYS, or a *command (either directly or using OSCLI), and that code Aborts with Data Transfer, Undefined Instruction or Instruction Fetch. The Error Line (ERL) then given by Basic is often the last line of the program, rather than the Basic line containing the CALL, USR, SYS or *command.

The useless ERL is very confusing, and does not help diagnosis, particularly when it is the only report from a user. It only tells the developer that there is a severe error somewhere in the program, which is little help. I know this lack of information has caused me, and many other developers, to waste countless hours just identifying where in the program the problem is, before the actual problem itself can be tackled. The larger the program, and the more external calls, the more wasted time – even with debugging aids (eg Reporter!)

A very simple example program purely to demonstrate the problem is:

    10 : ON ERROR PRINT REPORT$;" at line ";ERL:END
    20 : PRINT "START"
    30 : SYS "OS_File",0,&12345678 :REM Abort here
    40 :
    50 : PRINT "END"

There is a worse case when a command is executed from disc (either using OSCLI or without) and the command Aborts. A message ‘Attempt to use badly nested error handler (or corrupt r13)’ is given, then the Abort message (without any ERL), and then the program ends. This also applies to any aborting Module command which has changed R13_usr.

The Cause

The problem is caused when the Basic LINE pointer in R12 (which points to the current line) is corrupted, and that is used by Basic to find the program line number (ERL) after an error. If R12 is outside the program, ERL is currently set to zero or the last line of the program.

After an Abort in a SYS, or in a module *Command (issued direct or via OSCLI), R12 is always corrupted.

After an Abort in code executed from a CALL or USR then R12 is corrupted only if the called code changed it. However, I can find no recommendations in the Basic manual for register usage in code called by CALL or USR.

If R12 < PAGE then ERL is always set to 0 (and omitted by the default error handler).

If R12 > TOP the ERL is always set to the last line of the program.

If r13_usr has been corrupted, the Basic error handler is reset to the default, causing the program to end abruptly without any line number at all.

Possible Solutions

There would seem to be two possible ways to avoid the R12 corruption and provide a useful ERL:

1. Change the Kernel Abort Handlers to restore or avoid corrupting R12. This would seem to be very complex to achieve, although would probably be the least performance overhead.

2. Change Basic to enable it to recover R12 after an Abort. R12 could be saved on entry to, and restored after an Abort by the Basic error handling code. The possible options seem to be to save R12 either on the Basic stack (which is already done for CALL and USR), or somewhere in &8500-86FF. The overhead would be a single extra memory save for each CALL, USR or SYS, which seems very acceptable for the potential gains.

When r13_usr has also been corrupted, it would seem possible to restore r13 from the last error handler stack pointer in ARGSP-120, which then gives an error with an ERL, and enables the program to execute the current error handler. This is exactly what Basic does after an error anyway, if it thinks r13 was valid!

Proof of Concept

To see if it is practical to change Basic to avoid these problems, I have created a patched version of Basic v1.48 which corrects the ERL for all aborts without any observed detrimental effects.

If it can be agreed where R12 (corrected from ERL) should be stored, then I will change the Basic source to mimic the patched code, and run further tests. My suggestion is to free some valuable storage by removing from Basic all code associated with the TWIN (and possibly ARMBE) editors, which is surely unnecessary today?

I will be interested in any comments, either of support, or suggesting better ways to fix the problem, or things that I have missed or got wrong. Indeed, if anyone who knows the Basic source would like to cast their eyes over the details fo my work, please get in touch.

A very good idea. I had wondered why the last line number was returned.

I also found a quick way to identify the last line of a programme was to do a LIST with CTRL and SHIFT held down and then press Escape but that now seems to return the last line listed as the error line.

In all my large BASIC programs I use a dynamic LIBRARY system and make sure the last module starts with

REM some unknown place

so that BASIC reports

Data abort at line 10 in some unknown place

Which is meagre compensation I know, but saves staring at the wrong line.

Change Basic to enable it to recover R12 after an Abort.

I’ve never understood why BASIC is so lax about its Handlers. It would be easy to store the stack pointer on entry to any code or, indeed, a last-good-R12 (as memory corruption can also cause aborts).

If one was going to do that, I might be tempted to register the Handlers with the ARGP pointer as part of getting BASIC away from having to be based at &8000. It would be rather nice to be able to have ARGP somewhere else, sometimes.

It is a bit of a PITA, isn’t it?

However, I can find no recommendations in the Basic manual for register usage in code called by CALL or USR

There are some hints in the CALL branches routines section. ‘R12 = LINE (for error reporting)’ or variants are there for some, but not all, routines that require R12. It is certainly not clearly laid down, but I quickly found out that it was essential for Basalt. I have it explicitly documented in my private SH manual for the Basalt code:

‘The LINE pointer in R12 must not be overwritten because it is used for error reporting, which is not always under the control of Basalt code’

Perhaps I should have included that in the BASIC SH manual.

In a few keywords it was necessary to manipulate R12 to get an error reported at the most appropriate point.

To see if it is practical to change Basic to avoid these problems, I have created a patched version of Basic v1.48 which corrects the ERL for all aborts without any observed detrimental effects.

That sounds very interesting. How extensive is the patch?

If it can be agreed where the ERL should be stored, then I will change the Basic source to mimic the patched code, and run further tests.

Do you mean R12? The error routine calculates the ERL, doesn’t it?

This will only be available in new versions of the OS, I suppose, otherwise we come up against the barrier of softloaded BASIC. Nevertheless, it is a change that does not have to be backward compatible to be very useful. There are 5 words at the top of the arguments block that have not been specified AFAIK, although I have come across their unofficial use in the past.

My suggestion is to free some valuable storage by removing from Basic all code associated with the TWIN (and possibly ARMBE) editors, which is surely unnecessary today?

I am slightly confused as to why you are referring to this as storage. If you need room for the necessary code that will surely just be a matter of re-assembly after the source changes. There is only a vestige of TWIN/ARMBE in the application BASIC arguments space, and part of that is already overwritten.

In my PDP-11 version of BBC BASIC I update a LINE variable every time the program steps to the start of a new line, and on an error copy LINE to ERL, but that was mainly because on the PDP-11 I’ve only got six registers to play with.
I don’t have the ARM BASIC source in front of me at the moment, but how frequently does BASIC look for the current line in R12? I think my recommended solution would be to store the current line number in workspace each time a new line was encountered, ie when stepping past at the end of a line, or at a branch command (UNTIL, ENDWHILE, NEXT, ENDPROC, =, RETURN, GOTO, GOSUB); and then on an error transfer LINE to ERL instead of transfering R12 to ERL.
The other option of storing LINE somewhere only around a CALL/USR/SYS call is the error handler needs to know whether to fetch LINE from R12 or from the saved location. A way of doing it would be to set the workspace location to zero by default, and copy LINE to it before CALL/USR/SYS and clear it afterwards. The error handler would then use R12 only if the workspace location was zero, otherwise use the workspace contents for ERL. Sort-of-pseudo-ARM-ish code:

startup:
STR SV_LINE,#0
…
CALL/USR/SYS:
STR SV_LINE,R12
do CALL/USR/SYS
STR SV_LINE,#0
…
ERR_HANDLER:
LDRS SV_LINE,R0
STR SV_LINE,#0
MOVEQ R0,R12
STR R12,SV_ERL

> If it can be agreed where the ERL should be stored

You mean LINE, not ERL. Basic.Hdr.Workspace has a line that says:
; <- Insert new bits here

so that’s logically where to place extra workspace data, which by my quick mental arithmetic would put it at &86E8.

register the Handlers with the ARGP pointer

Sounds a much larger change than I was contemplating.

How extensive is the patch?

Suprisingly small – only about 20 (well chosen) instructions!

Do you mean R12?

Yup. Now corrected.

t the barrier of softloaded BASIC.

There must be some solution to that, surely?

I am slightly confused as to why you are referring to this as storage….. There is only a vestige of TWIN/ARMBE in the application BASIC arguments space, and part of that is already overwritten.

The storage I was referring to was the ‘vestige in the arguments space’ of which the first byte is used for something else. It will also remove more code from the module than I plan on adding, but that is incidental!

store the current line number in workspace each time a new line was encountered

A far larger change than I was planning, and a far larger overhead.

The other option of storing LINE somewhere only around a CALL/USR/SYS call is the error handler needs to know whether to fetch LINE from R12 or from the saved location.

Yup. Done that. Looks safe to me! And I have not been able to break it (yet).

It is a bit of a PITA, isn’t it?

Yes.

Really, BASIC should not be making any assumptions about the state of registers on return (i.e. BASIC should save state). While it is one thing to say to the user “don’t do this…”, what we see here is a fault condition where the OS “does stuff”. R12 is a private word pointer for modules on SWI call, for instance. There is nothing a user can do, for if an abort is taken, you’ll get tossed back to BASIC with a messed-up R12 whether you saved it or not. It’s BASIC’s responsibility.

Likewise USR mode R13 getting munged. If BASIC maintains its own copy, then this should be restored on exit from the assembler code and, at most, it should WARN you that R13 was messed up (indicating potential stack/unstack discrepancy); though this thankfully hasn’t happened to me yet, for one of the first things I do is stash R14 into the stack for later retrieval, so if the stack is messed up… ;-)

the barrier of softloaded BASIC.

There must be some solution to that, surely?

It has occured to me that packaging could be an answer to installing an up to date soft loaded BASIC just once. It would work for those who are happy to let packaging update their !System, and those who will update their !System manually when it is required by a new program, but it would still leave those who do neither out in the cold. I am not sure I can side with the group who would ‘force’ the package solution.

The storage I was referring to was the ‘vestige in the arguments space’ of which the first byte is used for something else.

MEMM. The words above that are the ones JGH and you and I are suggesting could be used, each in a different way. Be aware that there has been some juggling of the locations in that area of the arguments over the long life of BASIC, so I would go for the highest word.

so I would go for the highest word.

Oddly enough, that is exactly what I am using for testing!

Changes which should preserve the Basic ERL after an abort have today been included in the Development ROMs.

I hope this is seen as an improvement, and welcome to others!