A6 and the CALL command

[Martin_Head]

I have a machine code routine that is CALLed from Basic. It pushes A6 onto the stack at the start of the program, alters it, and then and Pops it off the stack before returning.

This is all works fine, but what if S*BASIC moves while the routine is being processed?

Will this crash the system? Or is S*Basic prevented from moving while doing a CALL command?

[tofro]

I would guess that as long as your code doesn't call any SBASIC traps and vectors (the ones that use a6 as argument), you should be safe. Your SBASIC program as such is halted during CALL, so if your code doesn't give SBASIC a reason to move, no one else will.

Tobias

[Martin_Head]

I don't know about SMSQ/E. But I thought that in QDOS, when a job is started, SuperBASIC moves down in memory, and the new job goes above it. Likewise if the job above SuperBASIC ends, SuperBASIC moves up.

Or have I got this all wrong?

[janbredenbeek]

I don't know about SMSQ/E. But I thought that in QDOS, when a job is started, SuperBASIC moves down in memory, and the new job goes above it. Likewise if the job above SuperBASIC ends, SuperBASIC moves up.

Or have I got this all wrong?

No, you're right at least with QDOS/Minerva. Under SMSQ/E and SBASIC, A6 doesn't move anymore as it points to a different memory area (I read this from a discussion that's now going on in the mailing list).

Jan.

[tofro]

My first answer applied to SMSQ/E, sorry for not pointing this out.

Note that, under SMSQ/E, the SBasic area doesn't move. If you write an extension, references thus needn't be relative to A6 during the entire processing. However, doing so will make your extension incompatible with QDOS.

I think this says the SBASIC **job** doesn't move - The various areas that pointers from the SBASIC job into areas on the common heap point to may change, however, their value when something moves.

This somehow allows you to write programs for SMSQ/E that would crash on an original QL. Whether that's acceptable or not, depends on what your program intends to do - If it cannot do the same thing on a real QL, (like high colors or other hardware), I see no point to achieve QDOS compatibility at any cost.

On a real QL, however, SBASIC tends to move all the time, as soon as the Transient Program Area needs to expand (like what happens when a new job is EXECuted) - Actually, moves appear to happen less frequently the more memory you have - So you can achieve some nice, tricky to find bugs by doing something forbidden. Thus, on a real QL, storing a6 somewhere in a SuperBASIC context or doing something like

Code: Select all

add.l a1, a6

To obtain a single register pointer to the RI stack, for example, is a no-no.

What actually happens when the system moves SuperBASIC is, in principle

1. the SuperBASIC job is halted, dumping the current registers (including a6) to the job header area
2. SuperBASIC is moved down in memory (to lower addresses) to expand it
3. the saved value of a6 is adjusted by the system
4. the SuperBASIC job comes back to "run" state and has its registers restored from the job header, with a "magically changed" a6

That means, code that runs within a SuperBASIC context, doesn't go into Supervisor mode and can thus be interrupted by the scheduler, can experience "sudden, irregular" changes of a6.

Tobias

[pjw]

I have a machine code routine that is CALLed from Basic. It pushes A6 onto the stack at the start of the program, alters it, and then and Pops it off the stack before returning.

This is all works fine, but what if S*BASIC moves while the routine is being processed?

Will this crash the system? Or is S*Basic prevented from moving while doing a CALL command?

In SuperBASIC this is a no-no, as external circumstances may cause the area to move even as your routine is executing. Your restored a6 will then be wrong.

In SBASIC (and compiled obj/tasks) no external events will move it around. However, certain calls you make within a m/c routine could cause areas within the SBASIC to move. But you initiate those calls yourself, so you will know when not to fiddle a6. Basically, you can consider a6 fixed - except around calls to a number of vectored utilities (NOT restricted to the fetching of parameters, or expanding the ri stack) when a6 should be correct on entry, and may have changed after the call.

[Pr0f]

Is a6 cached in the job header at start?

If so, you could either load it from there before ending your routine, there would be no need to stack it then either.

or could you use another address register?

[tofro]

Is a6 cached in the job header at start?
If so, you could either load it from there before ending your routine, there would be no need to stack it then either.

In QDOS, this doesn't help. a6 can change between any two instructions (Even worse, QDOS might assume SuperBASIC is where you make a6 point to). You simply cannot use for anything else but the SuperBASIC base pointer unless you go into supervisor mode.

Tobias

[Martin_Head]

Thanks for the replies. In the context of the routine I am referring to, I am only interested in SMSQ/E. So its not going to be a problem.

Just out of interest, Is there a good reason why A6 needs to be preserved on return from the CALL command? Why cant BASIC just insert the correct value for A6 on return from CALL?