Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SamuraiCrow]

bruceuncle wrote:
The linked list functions in AMOSPro.Lib are these:

All these functions use a very simple list element:

Lst_Next        rs.l            1       ; pointer to next element
Lst_Length      rs.l            1       ; length of user data
Lst_UserData    rs.b|w|l        nnn     ; user data

To use them from assembler code, just load the registers and JJsr L_Lst.xxxx.
(Where L_Lst,xxxx is the name of the function - the assembler picks this up from the +LEqu.s file in the includes.)

To use them from AMOS Basic, you need to load the registers using the Areg() and/or Dreg() statements.  Then emulate what the JJsr macro does:

        G_ADDR=(Leek(Areg(5)+$20)-(FunctionNumber*4)-40)
        Call Leek(G_ADDR)

(Where FunctionNumber is the number in brackets alongside each function below.)

This converts FunctionNumber into the correct offset from the library base:

Leek(Areg(5)+$20) is the base address of AMOSPro.Lib.
-40 is needed to skip over the library's header data.
FunctionNumber*4 indexes into the library's table of longword addresses to get to the entry for FunctionNumber.
Call Leek(G_ADDR) calls the function pointed to at that location.

L_Lst.ChipNew   (89)

Create a new list element in Chip memory (Chip|Clear|Public).
Will be initialised as the head element of an empty list.
IN: D0 = element length in bytes.
OUT: A0 = pointer to element address, D0 = length allocated (0=failed!).

L_Lst.New   (90)

Create a new list element in Fast memory (Clear|Public).
Will be initialised as the head element of an empty list.
IN: D0 = element length in bytes.
OUT: A0 = pointer to element address, D0 = length allocated (0=failed!).

L_Lst.Cree   (91)

Create a new list element in specified memory.
Will be initialised as the head element of an empty list.
IN: D0 = element length in bytes, D1 = memory flags (as for system AllocMem()).
OUT: A0 = pointer to element address, D0 = length allocated (0=failed!).

L_Lst.DelAll   (92)

Delete an entire list.
IN: A0 = pointer to head element.

L_Lst.Del   (93)

Delete a list element and free its memory.
IN: A0 = pointer to head element, A1 = pointer to list element to delete.

L_Lst.Insert   (94)

Insert a list element at the head of an existing list.
IN: A0 = pointer to head element, A1 = pointer to list element to be inserted.

L_Lst.Remove   (95)

Remove a list element (DOES NOT free its memory).
IN: A0 = pointer to head element, A1 = pointer to list element to remove.

Can these be added as commands?  Also, is the "List" token already in use?  I know that on old line-number BASIC editors the "list" command would show some or all of the lines of code.

[bruceuncle]

Apologies for taking a while to reply - we've got some tradies digging up the front yard to put new (not clay!) stormwater drainage in before winter really hits.  So I've been a bit distracted for a few days .

There's not much to stop us adding a few 'essential' instructions into a future AMOSPro.Lib.  I now understand what needs to be added to get the 'fast' interpreter binary file rebuilt when new instructions are added.  That's the incbin file in the source.  It's a binary of those end-of-line comments against each token.

Size is no real problem despite the 16-bit restrictions on Rbcc relocation branches.  It just needs careful planning  .

Whether these linked list instructions are worth the trouble is debatable.  I would prefer next and prior pointers and binary tree support for sorted lists.

We also need some easy way for AMOS programmers to define data structures to make linked lists really useful.  Something like a 'record' data type with definable 'fields' maybe.

Interesting food for thought.  Now back to bugs and the (now enormous and growing!) help file...

[SamuraiCrow]

For doubly-linked lists, we should make them compatible with the ones used by Exec.library.  Note that the internal commands contained in Exec.library are broken but the macros given in the C and Assembly libraries actually work.

It's a hybrid between a traditional NULL-terminated doubly-linked list and a circular doubly-linked list.  The list header contains a next pointer followed by a constant NULL (called tailpred in the structure), followed by a previous pointer.  If you want to access the front of the list you give a pointer to the top of the list header (or minimum list header as the autodocs call it) as your node pointer and if you want to index backward in the list, you give tailpred as the node pointer address so that forward looks like NULL and backward has a previous pointer.