A6 and the CALL command

Anything QL Software or Programming Related.
Martin_Head
Gold Card
Posts: 296
Joined: Tue Dec 17, 2013 1:17 pm

A6 and the CALL command

Postby Martin_Head » Fri Feb 16, 2018 11:08 am

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?


User avatar
tofro
QL Wafer Drive
Posts: 1372
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: A6 and the CALL command

Postby tofro » Fri Feb 16, 2018 11:22 am

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
Gold Card
Posts: 296
Joined: Tue Dec 17, 2013 1:17 pm

Re: A6 and the CALL command

Postby Martin_Head » Fri Feb 16, 2018 11:29 am

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?


User avatar
janbredenbeek
Gold Card
Posts: 252
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: A6 and the CALL command

Postby janbredenbeek » Fri Feb 16, 2018 12:03 pm

Martin_Head wrote: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.


User avatar
tofro
QL Wafer Drive
Posts: 1372
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: A6 and the CALL command

Postby tofro » Fri Feb 16, 2018 12:14 pm

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

SMSQ/E Reference Manual wrote: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


User avatar
pjw
Gold Card
Posts: 379
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: A6 and the CALL command

Postby pjw » Fri Feb 16, 2018 12:54 pm

Martin_Head wrote: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.


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
Pr0f
Gold Card
Posts: 283
Joined: Thu Oct 12, 2017 9:54 am

Re: A6 and the CALL command

Postby Pr0f » Fri Feb 16, 2018 1:39 pm

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?


User avatar
tofro
QL Wafer Drive
Posts: 1372
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: A6 and the CALL command

Postby tofro » Fri Feb 16, 2018 2:08 pm

Pr0f wrote: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
Gold Card
Posts: 296
Joined: Tue Dec 17, 2013 1:17 pm

Re: A6 and the CALL command

Postby Martin_Head » Sat Feb 17, 2018 10:36 am

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?



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 4 guests