Page 1 of 1

Memory management?

Posted: Mon Jan 11, 2021 9:20 am
by whuyse
The memory management in the DM42 puzzles me.
I had in the order of 6K bytes free, and wanted to see if a 42S trick worked on the DM42:

6K bytes is enough to hold a 10x10 complex matrix (it would take slightly more than half the memory), but you can't create it in the normal way:

Code: Select all

10
ENTER
NEWMAT
ENTER
COMPLEX
results in 'Insufficient Memory', because you need space for a real 10x10 as well.
In the 42S, that can be overcome by storing a 1x1 matrix in a variable and reDIMensioning it, as follows:

Code: Select all

01>LBL"NEWCMAT"
02 1
03 ENTER
04 NEWMAT
05 ENTER
06 COMPLEX
07 STO"."
08 Rv
09 DIM "."
10 RCL "."
11 CLV "."
12 END
Not surprisingly, the trick worked in the DM42 as well - but afterwards, I suddenly had 18K of free memory?

(I think there was a post on this before, but I can't find it because 'memory' is a 'too common word too search for'...)

Cheers, Werner

Re: Memory management?

Posted: Mon Jan 11, 2021 4:28 pm
by Dave Britten
I've noticed some odd behavior in the DM42's reported free memory as well. I'm guessing (i.e. I haven't read the source) that Free42 is just reporting the amount of memory that OS tells it is available, in other words however much it could malloc for its own use. You'll notice that editing a program and adding a few steps doesn't immediately change this value, so Free42 is presumably allocating memory in chunks, then using those chunks to store calculator data. The amount free will probably vary depending on what the DMCP OS has allocated for its own use, any garbage collection that happens either in the OS or in Free42, memory fragmentation in Free42, etc. Then this is all compounded by the fact that Free42 consumes memory faster than a real 42S, both because of the data registers being larger and higher precision, and program steps not being packed as tightly (a program that is reported as being 100 bytes is actually occupying about twice that, for instance).

In short, it's really hard to tell exactly how much free memory you've got left on the DM42. :) The same would be observed in Free42 running on other platforms, but since those platforms generally report several gigabytes of free memory, it's of little consequence.

I haven't done any empirical tests, but it "feels" like I can fit more in my upgraded 32 KB 42S than I can in the DM42, based on how quickly the reported free memory decreases.

EDIT: This might be the other thread you were thinking of, where I was discussing memory usage and allocation with Thomas.

viewtopic.php?f=15&t=2695

Re: Memory management?

Posted: Tue Jan 12, 2021 10:50 am
by whuyse
Ah, thanks Dave!
Werner

Re: Memory management?

Posted: Tue Jan 12, 2021 12:56 pm
by Thomas Okken
Dave Britten wrote:
Mon Jan 11, 2021 4:28 pm
I'm guessing (i.e. I haven't read the source) that Free42 is just reporting the amount of memory that OS tells it is available, in other words however much it could malloc for its own use.
Yes and no... the Free42 MEM calls a shell function, shell_get_mem(), and displays whatever it returns. So to understand how MEM works on the DM42, you'd have to look at the DM42 source code, since the shell_* functions are in the platform-specific code.

Note that Free42 only uses the value returned by shell_get_mem() to display when MEM is pressed, it doesn't use it to decide whether it can allocate a chunk of memory or not. Memory allocations are attempted and then checked to see if they succeeded, and Insufficient Memory is reported when a malloc() or realloc() call returns NULL.

So, depending on how shell_get_mem() is implemented on the DM42, it is entirely possible for malloc(N) to succeed while MEM shows a number smaller than N, or for malloc(N) to fail even though MEM shows a number larger than N. Undesirable, certainly. But possible.

Re: Memory management?

Posted: Tue Jan 12, 2021 3:12 pm
by Dave Britten
Thanks Thomas, that sounds pretty close to how I imagined it works.