memory allocator ?

[lemonyii]

it seems nice.
but in your code

Code: Select all

void operator new(size_t size) throw() { return malloc(size); }
void operator new[](size_t size) throw() { return malloc(size); }
void operator delete(void *p) throw() { free(p); }
void operator delete[](void *p) throw() { free(p); }

where did you call the constructor? or does C++ call it automatically just because it the new operator?

[Creature]

it seems nice.
but in your code

Code: Select all

void operator new(size_t size) throw() { return malloc(size); }
void operator new[](size_t size) throw() { return malloc(size); }
void operator delete(void *p) throw() { free(p); }
void operator delete[](void *p) throw() { free(p); }

where did you call the constructor? or does C++ call it automatically just because it the new operator?

AFAIK the constructor is indeed automatically called, it is what makes new different from malloc.

[lemonyii]

got it, thanks!

[Sam111]

Must the heap grow up and the stack grow down?

I would think the heap can grow any way you code it to.
Like if I start the heap start address at 0x1000000 then I should beable to make it grow down by
having my malloc implementation use the lower address's under 0x1000000. --

As for the stack this is more controlled by the hardware i.e push , pop , call ,...etc and what way they work on memory.

Curious though if you can do it.
Is their any machines that have stack growing up....

[Creature]

Must the heap grow up and the stack grow down?

I would think the heap can grow any way you code it to.

I would think the same, since the heap is usually entirely coded by the developer of the kernel/OS, you can choose yourself what you want it to be like. I think people opt for a heap that grows up because it seems more logical (low to high) and usually memory is laid out that way (e.g. 0 - 4 GB for 32-bit systems). In 64-bit and with the PML4 however, it may be feasible to have a heap that grows down for the part of the virtual address space that is negative.

[Sam111]

OK , how about the stack?

I can place it anywhere but call , push , pop , ret ,...etc force the stack to grow down I believe.
This is more ingranded in the hardware/opcodes how it will grow.

I am wondering is their any hardware/os out their that have the stack growing up?
Is it possible to effect the opcodes in some way as to have the stack grow up.

[StephanvanSchaik]

OK , how about the stack?

I can place it anywhere but call , push , pop , ret ,...etc force the stack to grow down I believe.
This is more ingranded in the hardware/opcodes how it will grow.

I am wondering is their any hardware/os out their that have the stack growing up?
Is it possible to effect the opcodes in some way as to have the stack grow up.

The ARM architecture generally supports stacks that grow down as well as up, whereas the x86(-64)-architecture only support stacks that grow downwards. You can have stacks that grow upwards, but the x86(-64) doesn't have native instructions that support this, hence why you should simulate such stack in that case.


Regards,
Stephan J.R. van Schaik.

[Sam111]

What do you mean by this

hence why you should simulate such stack in that case.

The instructions like call , pop , push , ret force it to grow downward on x86 machine.

That was cool to know about the ARM arch.... cool to know that push ,pop ,...etc work in reverse on that arch.


Anyway my thought is put the stack under the heap and have the heap grow upwards then no collisions can occur between the stack and the heap segments.

[StephanvanSchaik]

If you really need such a stack you should simulate it. By that I mean you should use the MOV, ADD, SUB, etc. instructions to get the job done.

Also, the ARM supports both methods, meaning that the stack can grow upwards, but doesn't necessarily have to.


Regards,
Stephan J.R. van Schaik.

[Owen]

ARM doesn't actually have PUSH/POP/CALL/RET* opcodes. It has

Code: Select all

STIA/STDA/STIB/STDB (Store increment after/decrement after/increment before/decrement before)
LDIA/STIA/STIB/STDB
BL/BLX (Branch and link, branch and link exchange)
B/BX (Branch/branch and exchange)
LDM/STM versions of each of the above LD/ST opcodes (Load/Store Multiple)

The standard ARM call frame is

Code: Select all

STMDB sp!, {r4-r7, lr} # Or as desired
... code ...
LDMIA sp!, {r4-r7, pc} # Or as desired

A longer form of the last one is
LDMIA sp!, {r4-r7, lr}
BX lr

* Thumb has PUSH/POP; they're a compressed form of STDB sp!/LDIA sp!. Thumb2 adds STDB/LDIA/STMDB/LDMIA opcodes to Thumb mode. You [i
can't[/i] have (efficient) upwards-moving stacks if you support Thumb code (as you probably want to do)

[Sam111]

Ok, I was think to use this algorithm for my malloc free
http://en.wikipedia.org/wiki/Buddy_memory_allocation Using powers of 2

Seems to be pretty efficient for a general OS.

curious in C does the function malloc , free ...etc call the OS memory allocator functions.
It must at some level... so when I use malloc on windows and use malloc on linux they must be coded to call the kernels memory allocator for the different OS you are using.

Also Curious what the windows xp or linux memory allocator functions are called and if I can bypass the malloc / free function calls and call the kernel equivalent?
Or is malloc/ free the only way you can call the memory allocators of the os (indirectly)

Their is no way to call them directly ? curious

[Owen]

On Unix, malloc (eventually) calls either mmap(2) or brk(2). free eventually calls either munmap(2) or brk(2).

[NickJohnson]

The buddy allocator is really designed for physical memory, where allocations are in large chunks, although you could somehow "layer" it with another allocator and use it decently for a heap in virtual memory. Not that it won't work, but it's probably less apt and more prone to internal fragmentation than an algorithm like dlmalloc (glibc's allocator).

The heap in the kernel and the heap used by processes are completely separate by the way. The kernel heap is useful for storing kernel objects, but user programs (at least when using protection and/or multitasking) couldn't possibly use the same heap, because it returns kernelspace memory that is mapped across all address spaces. Fortunately, if you are porting an existing libc (like newlib), that libc will already contain a heap implementation for userspace, so you don't have to worry about that.

[Sam111]

I have download newlib-1.18.0.tar.gz.
Do you know where the memory allocator code is in and what is it's name?

I don't see malloc or free here. Maybe I am missing something.

never mind found it in stdlib

[pcmattman]

Code: Select all

void operator new(size_t size) throw() { return malloc(size); }
void operator new[](size_t size) throw() { return malloc(size); }
void operator delete(void *p) throw() { free(p); }
void operator delete[](void *p) throw() { free(p); }

Don't forget placement new - very rarely used, but there's often one or two places it comes in handy in kernel programming.