newRPL: [UPDATED April 27-2017] Firmware for testing available for download
|
10-06-2016, 02:22 PM
(This post was last modified: 10-06-2016 07:04 PM by Bruno.)
Post: #408
|
|||
|
|||
RE: newRPL: [UPDATED September-17-16] Firmware for testing available for download
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: 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: 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': (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) { Any idea about that ? please, excuse my poor english |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)