newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Bruno]

Hi,

I'm still working on the MEM command to improve it's accuracy (and to improve my knowledge about newRPL internals ), and I need a little more help please.

PART 1 - MEM

I'll summarize here my understand about the memory structure, and how MEM is currently computing the User's free memory.

Firstly I needed to list all the memory regions and there respective sizes, and assess who is the owner (SYSTEM vs USER) :

SYSTEM'S MEMORY - 79KB - fixed size (See boot.c for details) :
- Volatile memory - 32KB
- Persistent memory - 47KB

USER'S MEMORY - 24KB - variable size :
- DSTK
- RSTK
- LAM
- DIRS
- TEMPBLOCKS
- TEMPOB

Secondly, I needed to determine how the user's memory is allocated:
-> Each region is allocated as a chunk of n * 4KB blocks, so for a fresh calculator, 6*4=24KB are used.

Thirdly, I needed to determine how to compute the current usage of each chunk (to be more accurate):
-> Using regions pointers

Fourthly, I needed to determine how many blocks are currently unallocated:
-> Using halGetFreePages() function dedicated to that purpose

Some research for a simple result :

Code:

    case MEM:
    {
        rplGCollect();

        BINT mem = halGetFreePages() << 12;

        mem += 4096 - ((DSTop - DStk) & 0xFFF);
        mem += 4096 - ((RSTop - RStk) & 0xFFF);
        mem += 4096 - ((LAMs - LAMTop) & 0xFFF);
        mem += 4096 - ((DirsTop - Directories) & 0xFFF);
        mem += 4096 - ((TempBlocksEnd - TempBlocks) & 0xFFF);
        mem += 4096 - ((TempObEnd - TempOb) & 0xFFF);

        rplNewBINTPush((BINT64)mem, DECBINT);

        return;
    }

But I still have some interogations :

- halGetFreePages() returns 404KB of free ram, so 108KB of memory allocated for a fresh newRPL installation,
but I've identified 'only' 103KB (79 + 24) of different memory regions, it stay 5KB of unknown memory, what am I missing ?

- My guess about the regions ownership (USER vs SYSTEM) helped me to determine for which regions MEM needs to compute the actual use,
but is it my guess right ?

Of course, any comment, correction and best practice about the code are welcome.

Successives call of MEM : (After each call, from 5 to 9 bytes of memory are used, I don't know why at the moment)


PART 2 - VERSION

I would like to implement the VERSION command, and as a simple demo I try this code :

Code:

    case VERSION:
    {
        char version[] = "newRPL alpha0.6.01";
        char copyright[] = "(c) Claudio Lapilli";

        WORDPTR versobj = rplCreateString((BYTEPTR)version, (BYTEPTR)version + stringlen(version));
        if(!versobj) return;

        WORDPTR copyobj = rplCreateString((BYTEPTR)copyright, (BYTEPTR)copyright + stringlen(copyright));
        if(!copyobj) return;

        rplPushData(versobj);
        rplPushData(copyobj);
        return;
    }

but I was unable to compile the ROM because gcc seems to do an implicit call to 'memcpy' that the linker was unable to resolve :

Code:

lib-65-system.o: In function `lib65_handler':
lib-65-system.c:(.text+0x4e0): undefined reference to `memcpy'
Makefile:497: recipe for target 'newrplfw.elf' failed
collect2: error: ld returned 1 exit status

(My guess about the origin of the memcpy is the copy of the string from the ROM to the RAM, but I'm not sure)

As a workaround, I overloaded the memcpy, and the compilation succeeded :

Code:

void *memcpy(void *dest,const void *source,int nwords) {
    memcpyb(dest, source, nwords);
    return dest;
}

Any idea about that ?