Executables and initial register values

[copse]

I posted in another thread about my experiments with vamos/amitools. One of the things I've come up against, is a reliance by a C program on something I haven't found documented.

Specifically, the "main" executable from Pools of Radiance does the following:

movem.l    D1-D6/A0-A6, -(SP)
...
move.l      SP, D0
sub.l        4(SP), D0
...
move.l      D0, (hSPLower-DT,A4)

Now, it is documented that 4(SP) is the stack size. But the movem clobbers the initial stack address, and in turn moves the stack back a long word, places A6, moves the stack back long word, places A5 ............ moves the stack back a long word, places D6, .......... moves the stack back a long word, places D2, moves the stack back a long word, places D1.

So by what I assume is complete coincidence, the C compiler writer does not bother to save D0, leaving D1 at 0(SP) and D2 at 4(SP). And Amiga OS from 1.2 to 3.1 happen to have the stack size in D2.

Thoughts?

[Leffmann]

I don't think it's a coincidence, the programmers probably found it to be the case on all versions of AmigaOS they tested and just assumed it would always work. It may not be the case on later versions of Dos and Exec, and it only works on the command line, not if you run from Workbench.

The only registers and values that are defined and reliable are, when on the command line, A0, pointer to the command string, and D0, the length of the command string.

[copse]

Originally Posted by Leffmann

I don't think it's a coincidence, the programmers probably found it to be the case on all versions of AmigaOS they tested and just assumed it would always work. It may not be the case on later versions of Dos and Exec, and it only works on the command line, not if you run from Workbench.

Hmm. What OS calls are involved to run from Workbench? I'd like to look into this, but it's been so long that I do not recall what is involved.

Note that Pool of Radiance has a hard drive installer. This executable relies on D2 providing the stack size both when started from DOS, and from Workbench.

Originally Posted by Leffmann

The only registers and values that are defined and reliable are, when on the command line, A0, pointer to the command string, and D0, the length of the command string.

Originally Posted by AmigaDOS Developer's Manual (1985)

AmigaDOS pushes a suitable return address onto the stack that tells the CLI to regain control and unload your program. Below this on the stack at 4(SP) is the size of the stack in bytes, which may be useful if you wish to perform stack checking.

And that is what the C program is doing, stack checking. Albeit I assume incompetently in a way that happens to work through coincidence.

[alkis]

Originally Posted by copse

... the C compiler writer does not bother to save D0, leaving D1 at 0(SP) and D2 at 4(SP). And Amiga OS from 1.2 to 3.1 happen to have the stack size in D2.

Thoughts?

It's my understanding that AmigaShell expects the return code of the program in D0 (RC)...so, unless I missread you, the C compiler writer correctly doesn't save D0.

[copse]

This is about the other side of the coin, the registers that are provided when the program starts. e.g. A0 for argument strings, D0 for argument count, 4(SP) for stack size, and perhaps D2 for stack size unofficially.

[Leffmann]

Originally Posted by copse

Hmm. What OS calls are involved to run from Workbench? I'd like to look into this, but it's been so long that I do not recall what is involved.

In short, FindTask, WaitPort, GetMsg, Forbid and ReplyMsg. FindTask can be omitted if you want to get your task pointer from inside execbase instead.

Originally Posted by copse

Note that Pool of Radiance has a hard drive installer. This executable relies on D2 providing the stack size both when started from DOS, and from Workbench.

That's a mistake then, because as far as CPU registers goes A0 and D0 will be set as discussed, and that's it. Other registers are officially undefined, and if you run from Workbench then all registers are undefined (unless you use the CLI tooltype under 2.0 or later).

[copse]

Originally Posted by Leffmann

In short, FindTask, WaitPort, GetMsg, Forbid and ReplyMsg. FindTask can be omitted if you want to get your task pointer from inside execbase instead.



That's a mistake then, because as far as CPU registers goes A0 and D0 will be set as discussed, and that's it. Other registers are officially undefined, and if you run from Workbench then all registers are undefined (unless you use the CLI tooltype under 2.0 or later).

You're right. I went back and checked the code, and it does something like:

    move.l ThisTask(A6), A3
    tst.l    pr_CLI(A3)
    beq.b  wbstartup
...
wbstartup:
    move.l pr_Task+TC_SPLOWER(A3), splower

Which would work fine for hd installs and whatnot.

[ross]

From what I remember there is a complete BCPL environment available for executables launched from the CLI.
I have no idea if the 3.1.4 ROMs continue to support it, but it was until 3.1 OS.
Some legacy TripOS commands from AmigaDos 1.x still used the environment, only to be deprecated (rightly..) by version 2.x.

INITIAL ENVIRONMENT

        Upon entry to any BCPL routine, the register contents are as follows:

        d0 - amount of global area currently in use
        d1-d4 - up to 4 parameters.  Further parameters can be passed on
                the stack (see below).
        d5-d7 - unused
        a0 - base of system address space - always 0.
                RAM addresses are computed as offsets from a0
        a1 - base of the current BCPL stack frame
        a2 - pointer to the BCPL Global Vector
        a3 - return address of the caller
        a4 - entry address
        a5 - pointer to a "caller" service routine
        a6 - pointer to a "returner" service routine
        a7 - stack for temporaries

        This register environment is available to any application program.

Not all parameters are available, also because it would not make sense to do so, and they have been reused by the CLI environment for passing parameters from the command line:

The parameters passed by the CLI to an application are:
        d0 - length of command line
        a0 - APTR to command line
The command itself may be found in the CLI->cli_Command field.

In practice all the Dx registers are useless (apart from the new use of D0) because the parameters are passed from the command line.
But interesting is that D1-D4, unused and unusable parameters, are still saved in the current BCPL stack frame (A1).
A0 instead of having the value 0, used in the ancient environment for funny addressing mode like (A0=0, Dx), with Dx=mem_address or BPTR (and this explains the absurd way of AmigaDos to have as parameters the addresses in the data registers..), is used for an APTR to command line.
The other values of the address registers retain their original function, apart from A3 and A4 which are 'scratch registers' and used by service routines.
Interesting is that A3 is used by practically all ROMs as a jump register within the starting hunk and some crunchers had used it for their purposes, but it was just a coincidence because it was one of the scratch registers available.
And in fact for AROS ROMs this is not true and there have been compatibility problems.

A long time ago I also tried to figure out if the initial setting of these registers could have any use for a generic program, but no, I couldn't even find a way to use them to get the base of dos.library without using OpenLibrary() from Exec..

So forget it and just use D0 and A0

[hop]

Sorry to resurrect this old thread, but it seems related.

I just read in the Amiga Guru Book (p574) that for CLI programs:

None of the register contents (with the possible exception of the stack pointer) need be preserved by the program and therefore need not be restored upon return.

I never realised this. I think I got in to a habit of doing this years ago after following a tutorial and it has stuck:

	movem.l	d1-d7/a0-a6,-(a7)
	<program>
	movem.l	(a7)+,d1-d7/a0-a6	
	moveq	#0,d0
	rts

I guess the same applies to programs launched from Workbench, and the only time it makes sense to preserve registers in a program is if you are going to

jsr

into it from your own code and need to respect calling conventions.

[alkis]

Originally Posted by ross

A long time ago I also tried to figure out if the initial setting of these registers could have any use for a generic program, but no, I couldn't even find a way to use them to get the base of dos.library without using OpenLibrary() from Exec..

So forget it and just use D0 and A0

Well, we found this when squeezing for the pi computation.

lea -$148(a2),a6 ; dos library from bcpl vector

[alkis]

Originally Posted by hop

Sorry to resurrect this old thread, but it seems related.

I just read in the Amiga Guru Book (p574) that for CLI programs:



I never realised this. I think I got in to a habit of doing this years ago after following a tutorial and it has stuck:

	movem.l	d1-d7/a0-a6,-(a7)
	<program>
	movem.l	(a7)+,d1-d7/a0-a6	
	moveq	#0,d0
	rts

I guess the same applies to programs launched from Workbench, and the only time it makes sense to preserve registers in a program is if you are going to

jsr

into it from your own code and need to respect calling conventions.

That's correct.