Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

[Development] Stack Vs Heap Memory Allocationpage  1 2 

Samuel Devulder

Posts 248
20 Mar 2020 12:54


So, you never heard of static storage in C. Storage classes (register, auto, extern, static) are within the basics of the language. BSS is just the asm version of it.


Olle Haerstedt

Posts 110
20 Mar 2020 16:59


Samuel Devulder wrote:

So, you never heard of static storage in C. Storage classes (register, auto, extern, static) are within the basics of the language. BSS is just the asm version of it.

That has a very easy explanation: I don't know C. Nor ASM.


Olle Haerstedt

Posts 110
23 Mar 2020 22:15


Fun fact: AmiBlitz seems to use a pool for their array implementation: https://github.com/AmiBlitz/AmiBlitz3/blob/master/Sourcecodes/Amiblitz3/BlitzLibs/ACIDLIBS/arrayslib.ab3#L100


Stefan "Bebbo" Franke

Posts 139
25 Mar 2020 12:04


Thumb rule:

If the memory is no longer in use when your function returns, use the stack.

The only exception: Your stack is limited and maybe not large enough.

Q: Why use the stack?
A: there is no alloc/free cost, no overhead => fastest way

Q: What if the stack is limited?
A: if you know the max required stack size, enforce that stack size

- check the stack size and abort with an appropriate message:
  "set stack to ..."
  "start me using the icon - and the icon sets the stack size"
- use swapstack

Q: What if the stack can't be used?
A: Use the memory management of your preference :-)




Olle Haerstedt

Posts 110
25 Mar 2020 21:22


Stefan "Bebbo" Franke wrote:

Thumb rule:
 
  If the memory is no longer in use when your function returns, use the stack.
 
  The only exception: Your stack is limited and maybe not large enough.
 
  Q: Why use the stack?
  A: there is no alloc/free cost, no overhead => fastest way
 
  Q: What if the stack is limited?
  A: if you know the max required stack size, enforce that stack size
 
  - check the stack size and abort with an appropriate message:
    "set stack to ..."
    "start me using the icon - and the icon sets the stack size"
  - use swapstack
 
  Q: What if the stack can't be used?
  A: Use the memory management of your preference :-)
 

Not so common to enforce a specific stack size on Amiga, right? But definitely possible. And especially if it speeds things up.

Next step would be to not use any dynamic data structures, like linked lists. E.g., if the hero can shoot max 5 bullets at any time, then keep an array of size 5 ready and keep looping it, ignoring empty cells. Doing priority queues or trees this way I don't know how atm.


Olle Haerstedt

Posts 110
25 Mar 2020 21:46


I really like this quote:

"The trick is to not use the same allocator when the lifetime is different.

Some resources are allocated once and basically never freed.

Some resources are allocated per level and freed all at once at the end.

Some resources are allocated during a frame and freed all at once when a new frame starts.

And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) "

From: EXTERNAL LINK


Stefan "Bebbo" Franke

Posts 139
25 Mar 2020 21:57


Olle Haerstedt wrote:

I really like this quote:
 
  "The trick is to not use the same allocator when the lifetime is different.
 
  Some resources are allocated once and basically never freed.
 
  Some resources are allocated per level and freed all at once at the end.
 
  Some resources are allocated during a frame and freed all at once when a new frame starts.
 
  And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) "
 
  From: EXTERNAL LINK 

easy-peasy


  mainFx()
    alloc global stuff (stack or global)
    call level's function
    each levelFx()
      alloc level's stuff (stack or global)
      play level
        frame loop
      free level's stuff
    free global stuff

And
* you must/should not allocate stuff per level. Preallocate everything per level.
* free your stuff at game end



Olle Haerstedt

Posts 110
25 Mar 2020 22:12


Stefan "Bebbo" Franke wrote:

 
Olle Haerstedt wrote:

  I really like this quote:
   
    "The trick is to not use the same allocator when the lifetime is different.
   
    Some resources are allocated once and basically never freed.
   
    Some resources are allocated per level and freed all at once at the end.
   
    Some resources are allocated during a frame and freed all at once when a new frame starts.
   
    And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) "
   
    From: EXTERNAL LINK   

 
 
  easy-peasy
 
 

    mainFx()
      alloc global stuff (stack or global)
      call level's function
      each levelFx()
        alloc level's stuff (stack or global)
        play level
          frame loop
        free level's stuff
      free global stuff
 

 
  And
  * you must/should not allocate stuff per level. Preallocate everything per level.
  * free your stuff at game end
 
 

 
  Yes, that makes sense. And then either use a static buffer or ask OS for a block of memory at program/level start, allocate by incrementing the pointer and free everything at end. All assuming your memory consumption is "reasonable" and pretty simple. :) Advanced algorithms maybe complicate this. What about the memory consumption of the A* algorithm, for example?


Olle Haerstedt

Posts 110
25 Mar 2020 22:24


Another brilliant quote about memory pooling:

"there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well."

Now that I like. :D


Stefan "Bebbo" Franke

Posts 139
26 Mar 2020 17:03


Olle Haerstedt wrote:

Another brilliant quote about memory pooling:
 
  "there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well."
 
  Now that I like. :D

if you test thoroughly and estimate reasonably, you can work well with the remaining deficits.

It is better to have a playable game with a maximum of 256 bullets than a game with an unlimited number that sucks.

I hate people who complain, but have not achieved anything themselves.


Olle Haerstedt

Posts 110
26 Mar 2020 19:33


Stefan "Bebbo" Franke wrote:

Olle Haerstedt wrote:

  Another brilliant quote about memory pooling:
 
  "there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well."
 
  Now that I like. :D
 

 
  if you test thoroughly and estimate reasonably, you can work well with the remaining deficits.
 
  It is better to have a playable game with a maximum of 256 bullets than a game with an unlimited number that sucks.
 
  I hate people who complain, but have not achieved anything themselves.

Sure. Don't think it was meant as complaining as much as an interesting time-typical factoid of earlier computing. Most people in the thread seemed to be devs.

posts 31page  1 2