execbase in assembler question

[Displacer]

I have several books on programming the Amiga, and I'm learning to code in assembler on it. Question I have is something that is confusing about the exec library. I've looked at some assembly code that refers to the CoolCapture vector. In the code that I looked at, its absolute address is (assuming A6 holds offset 0)

$2E(A6)

But looking in the docs I have, specifically execbase.h the structure is listed as:

Code: [Select]

   UWORD    SoftVer;    /* kickstart release number (obs.) */
    WORD    LowMemChkSum;    /* checksum of 68000 trap vectors */
    ULONG    ChkBase;    /* system base pointer complement */
    APTR    ColdCapture;    /* coldstart soft capture vector */
    APTR    CoolCapture;    /* coolstart soft capture vector */
    APTR    WarmCapture;    /* warmstart soft capture vector */
    APTR    SysStkUpper;    /* system stack base   (upper bound) */
    APTR    SysStkLower;    /* top of system stack (lower bound) */
    ULONG    MaxLocMem;    /* top of chip memory */
    APTR    DebugEntry;    /* global debugger entry point */
    APTR    DebugData;    /* global debugger data segment */
    APTR    AlertData;    /* alert data segment */
    APTR    MaxExtMem;    /* top of extended mem, or null if none */

    UWORD    ChkSum;    /* for all of the above (minus 2) */
Which puts the offset at 0C from the start of this structure, so what am I missing?

Thanks!

[Karlos]

Remember that struct ExecBase is an extended library base. Therefore, it starts with an embedded struct Library. You have to add the (aligned, IIRC) size of that to your offset. In C terms, that's

Code: [Select]

struct ExecBase {
  struct Library LibNode;

  UWORD SoftVer;

  /* other fields... */

};

Look in your includes for exec/libraries.h to see that structure.

[Lando]

Hi,

struct Library LibNode;

comes before

UWORD   SoftVer;

in the execbase structure, which would explain the missing bytes.

[Displacer]

OK, I missed the Library struct. I went back and counted the bytes again, and still can't come up with the right number. I think it's the NODE struct in the Library struct that's messing me up. It has the comment that it's word aligned so what is the size exactly of the NODE struct? Sorry for all the questions and I hope it's the alignment that's messing me up instead of just not being able to count

[Piru]

Code: [Select]

  STRUCTURE    LN,0
        APTR    LN_SUCC ; 0
        APTR    LN_PRED ; 4
        UBYTE   LN_TYPE ; 8
        BYTE    LN_PRI  ; 9
        APTR    LN_NAME ; 10
        LABEL   LN_SIZE ; 14

 STRUCTURE LIB,LN_SIZE
    UBYTE   LIB_FLAGS                   ; 14
    UBYTE   LIB_pad                     ; 15
    UWORD   LIB_NEGSIZE         ; 16
    UWORD   LIB_POSSIZE         ; 18
    UWORD   LIB_VERSION         ; 20
    UWORD   LIB_REVISION                ; 22
    APTR    LIB_IDSTRING                ; 24
    ULONG   LIB_SUM                     ; 28
    UWORD   LIB_OPENCNT         ; 32
    LABEL   LIB_SIZE    ;34

 STRUCTURE  ExecBase,LIB_SIZE
        UWORD   SoftVer ; 34
        WORD    LowMemChkSum    ; 36
        ULONG   ChkBase ; 38
        APTR    ColdCapture     ; 42
        APTR    CoolCapture     ; 46 = $2E


[ChaosLord]

Piru FTW!

[Displacer]

Ah, there's the problem. The node struct I have is:

Code: [Select]

struct Node {
    struct  Node *ln_Succ;
    struct  Node *ln_Pred;
    UBYTE   ln_Type;        
    BYTE    ln_Pri;
    char    *ln_Name;
};

[Piru]

Ah, there's the problem.

Where?

The node struct I have is:

Code: [Select]

struct Node {
    struct  Node *ln_Succ;
    struct  Node *ln_Pred;
    UBYTE   ln_Type;        
    BYTE    ln_Pri;
    char    *ln_Name;
};

This is exactly the same as the STRUCTURE LN in nodes.i.

[Displacer]

I know it is, sorry I wasn't clear. What I meant is the char is what messed me up. I was treating that entry as a char (single byte) instead of APTR (4 bytes) and that's exactly how far my count was off. My own fault

Thanks for the help!

[Karlos]

Wouldn't have been a very long label if it was a single char. Having said that, it was enough for Microsoft's drive enumeration scheme for years :lol: