That would of course be even better, the compiler could calculate if
vars+stack+heap fit in the given memory configuration and issue at
minimum a warning or even better a compile error.
But this is definitely something that is out of my league, Florin, could
you implement this?
Michael
Am 03.03.13 21:45, schrieb Florian Klämpfl:
> Am 03.03.2013 21:27, schrieb Michael Ring:
>> I have created a new patch, this time it uses the values of the two
>> commandline parameters -Ch and -Cs to set the size of Stack and Heap. I
>> am not sure if those params were for this use case but in my opinion it
>> makes sense.
>>
>> Florian, could I ask you to apply the patch to trunk if what I am doing
>> is is ok?
>
> It looks reasonable, but after some thinking I came to the conclusion
> that maybe the heap should be already allocated during linking, i.e. so
> heapmgr does not need to calculate an _heap_start.
>
>>
>>
>> Index: rtl/embedded/heapmgr.pp
>> ===================================================================
>> --- rtl/embedded/heapmgr.pp (revision 23681)
>> +++ rtl/embedded/heapmgr.pp (working copy)
>> @@ -34,7 +34,13 @@
>>
>> var
>> Blocks: PHeapBlock = nil;
>> + _heap_start : pointer;
>> + _heapsize: longWord; external name '__heapsize';
>> + _stklen: longword; external name '__stklen';
>> + _bss_end: record end; external name '_bss_end';
>> + _stack_top: record end; external name '_stack_top';
>>
>> +
>> procedure InternalFreeMem(Addr: Pointer; Size: ptruint); forward;
>>
>> function FindSize(p: pointer): ptruint;
>> @@ -242,6 +248,11 @@
>>
>> initialization
>> SetMemoryManager(MyMemoryManager);
>> + _heap_start := @_stack_top - _heapsize - _stklen;
>> + // Only initialize Heap when there is enough space available
>> + if _heap_start >= @_bss_end then
>> + RegisterHeapBlock(_heap_start,_heapsize);
>> +
>> finalization
>> //FinalizeHeap;
>> end.
Am 03.03.13 12:36, schrieb Michael Ring:
This helped me to understand another puzzle piece.
Please correct me if I am wrong:
sram - Memory is divided in several areas on arm-embedded:
_data starts at start of sram ($20000000 in my case)
_edata is end of _data segment ($200009b4)
_bss_start defines start of static vars ($200009b4)
_bss_end defines end of static vars ($20000e90)
all memory from here on is used for stack, stack grows from end of
avaliable sram ($20010000) downto _bss_end
so what I could do is allocate memory for heap starting at address
_bss_end with the size of _heapsize. or, perhaps even better:
I start using memory at address _stack_top - _stklen - _heapsize
Correct ??
Michael
Am 03.03.13 11:14, schrieb Sven Barth:
On 03.03.2013 11:04, Michael Ring wrote:
For a little more flexible solution I would like to ask you one more
questions, it may seem dumb to you but I have never been that deep into
a compiler before so I am learning a lot atm.
I can see that the compiler param -Ch can be used to define the
heapsize, I can also see in the assembler code of my main program that
when I set -Ch I also get a section:
-Ch2048 results in this:
.section .data.n___heapsize
.balign 4
.globl __heapsize
__heapsize:
.long 2048
but I do not seem to be able to access __heapsize in my code, how could
I use this information to make the heapsize configurable?
Did you try
=== code begin ===
var
heapsize: LongWord; external name '__heapsize';
=== code end ===
?
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
