This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to malloc from the beginning of init_mempool.

Hi, there,

The malloc always allocate memory at the tail of the memory initialized by init_mempool(). How to make "malloc()" allocate memory from the beginning of the initialized memory?

In details, suppose running following code fragment,

  byte xdata *M1;
  byte xdata *M2;
  init_mempool (&XBYTE [0x10], 0x1000);
  M1 = (byte xdata *) malloc (500);
  M2 = (byte xdata *) malloc (100);

The initialized memory starts from 0x10, ends at 0x1010. M1 starts from 0x0E1C to 0x1010, while M2 starts from 0x0DB4 to 0x0E18, with 4 bytes gaps from M1 and M2.

My question is how to allocate M1 so as to start from 0x0010, end with 0x0204? And then M2 starts with 0x0208 and ends with 0x026C?

thanks,
Kan

Parents
  • "The codes assume that the malloc starts from the beginning of the available memory."

    But, as Hans-Berhard said, does it actually make any difference whether or not this is true?
    It shouldn't, since there is no guarantee that it's true!

    Can you explain why it makes a difference?

    This should immediately be flashing big red lights and sounding loud warning bells: if your code is making this blatantly unwarranted assumption, what others are going to be lurking deeper down...
    Time to start adding contingency to your project plan, methinks!

    "(2) change the way that the current codes use malloc()."

    Particularly on an 8051 target, the best idea would probably be to change it to stop using malloc() altogether!!

    I have done this in the past, and it wasn't that hard.
    You may well find that directly accessing statically-allocated data gives you both improved performance and reduced code size (rather than having to go via pointers).
    Again, on an 8051 this could be significant.

Reply
  • "The codes assume that the malloc starts from the beginning of the available memory."

    But, as Hans-Berhard said, does it actually make any difference whether or not this is true?
    It shouldn't, since there is no guarantee that it's true!

    Can you explain why it makes a difference?

    This should immediately be flashing big red lights and sounding loud warning bells: if your code is making this blatantly unwarranted assumption, what others are going to be lurking deeper down...
    Time to start adding contingency to your project plan, methinks!

    "(2) change the way that the current codes use malloc()."

    Particularly on an 8051 target, the best idea would probably be to change it to stop using malloc() altogether!!

    I have done this in the past, and it wasn't that hard.
    You may well find that directly accessing statically-allocated data gives you both improved performance and reduced code size (rather than having to go via pointers).
    Again, on an 8051 this could be significant.

Children
  • Hi, there,

    Actually, my previous understanding was not correct. The codes don't have the erroneous assumption that the malloc must start from the beginning of the memory.

    What happened yesterday was that when I init_mempool(), I didn't assign an aligned value to be the size of initialized memory(0xFF00). Hence, M1 is not the expected 0xFD0C, instead it is 0xFD1C. And then M2 is not 0xFF00, but 0xFF10 which is out of the available memory.

    After I changed the init_mempool size to be 0xFE00, the problem is solved.

      init_mempool (&XBYTE [0x10], 0xFF00);
      M1 = (byte xdata *) malloc (500);
      M2 = M1 + 500;
    

    For the second question, the reason that we cannot get rid of all malloc() is that we are implementing a Java VM. We don't know what Java class that the users will use until runtime. Hence, we cannot statically malloc the java classes beforehand.

    Do I understand your suggestion clearly, Andy?

    many thanks,
    Kan