10-06-2016, 02:22 PM (This post was last modified: 10-06-2016 07:04 PM by Bruno.)
Post: #408
 Bruno Member Posts: 74 Joined: Sep 2014
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; }