Heap Manager Structure
Heap Manager Structure
Hi. You see attachment. When i created a space for an object, i will start to reserve area from 0x00000000. Is this true? Example, in attachment, Object1 pointer address value is 0. And also, Object2 pointer address value is Object1 size.
I ask this question, because i used malloc in C++. And looked to pointer value, it isnt 0. And i have suspected.
I ask this question, because i used malloc in C++. And looked to pointer value, it isnt 0. And i have suspected.
- Attachments
-
- Heap and Stack Structure
- Stack and Heap.png (7.44 KiB) Viewed 1412 times
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
depending on your implementation, malloc will store some metadata in the heap itself, with the result that return values of 0 generally dont occur. Besides, that value also means a NULL pointer which can horribly confuse your code should you get it.
Also, the stack grows downward. That means that ESP starts at some high address and decrements to lower addresses when the stack expands.
Also, the stack grows downward. That means that ESP starts at some high address and decrements to lower addresses when the stack expands.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
The Heap and Stack are located in two different segments, DS (Heap) and SS (Stack). In case DS equals SS, then the heap can indeed start at SS:0 (since it would equal DS:0)
Maybe you're not a native speaker, but still, may i suggest you to formulate your questions such that we can see what you are up to, instead of answering something that sounds like "is this the correct approach" which comes close to asking someones opinion.
Maybe you're not a native speaker, but still, may i suggest you to formulate your questions such that we can see what you are up to, instead of answering something that sounds like "is this the correct approach" which comes close to asking someones opinion.
Most 32-bit C++ compilers will assume DS and SS are equivalent. But the machine code they generate will typically use DS, since it's the default for most registers.Tolga wrote::S In C++, when we use a pointer, it uses which segment? DS or SS?
16-bit compilers compilers will usually store the segment as part of the pointer value, so they should reload one of the segment registers with the segment value in the pointer and use that segment register. This will probably not be SS, though.
This is all x86-specific, of course.
If i create Code, Data and Stack Segments in GDT before application starting , does compiler use SS for pointer?But the machine code they generate will typically use DS, since it's the default for most registers.
I will adjust SS and DS with different values. If compiler assumes DS and SS are equivalent, maybe i allocate some space on application code. Because DS = CS.[/quote]
-
- Member
- Posts: 134
- Joined: Sun Oct 24, 2004 11:00 pm
- Location: North Dakota, where the buffalo roam
No. It's hard to generalize when you haven't even told us what compiler you're using, but gcc for instance, is completely unaware of the possibility of non-overlapping segments. Or, put another way, it pretends the segmentation mechanism doesn't even exist. So, it doesn't even look at the GDT, and I think it will be almost impossible to make it generate code with pointers relative to SS.Tolga wrote:If i create Code, Data and Stack Segments in GDT before application starting , does compiler use SS for pointer?
If you are using a segmentation-aware compiler, which generates 32-bit segmented code, and manages your GDT for you, that may be different, I don't know. I don't even know if such a compiler exists.
Hi,
Now consider the code you'd need in "showCharacter()", and don't forget that "foo" would be in a data segment while "bar" is on the stack.
Basically, every pointer would need to consist of a segment and an offset, and you'd be constantly doing slow segment register loads.
Cheers,
Brendan
For compilers (and code in general), supporting segmentation would be a nightmare. For an example:rexlunae wrote:No. It's hard to generalize when you haven't even told us what compiler you're using, but gcc for instance, is completely unaware of the possibility of non-overlapping segments. Or, put another way, it pretends the segmentation mechanism doesn't even exist. So, it doesn't even look at the GDT, and I think it will be almost impossible to make it generate code with pointers relative to SS.Tolga wrote:If i create Code, Data and Stack Segments in GDT before application starting , does compiler use SS for pointer?
If you are using a segmentation-aware compiler, which generates 32-bit segmented code, and manages your GDT for you, that may be different, I don't know. I don't even know if such a compiler exists.
Code: Select all
char foo = 'a';
void main(void) {
char bar = 'b';
showCharacter(&foo);
showCharacter(&bar);
}
void showCharacter(char *c) {
printf("%c\n", *c);
}
Basically, every pointer would need to consist of a segment and an offset, and you'd be constantly doing slow segment register loads.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
- Member
- Posts: 134
- Joined: Sun Oct 24, 2004 11:00 pm
- Location: North Dakota, where the buffalo roam
I'm not saying there is a modern 32-bit compiler that is aware of segmentation, but I'm acknowledging that I don't know about every compiler, and it isn't completely impossible. Keeping track of what segment a variable is in would become feasible if you made the pointers all 48-bit far pointers, but most compiler writers lack the necessary level of insanity.Brendan wrote:Basically, every pointer would need to consist of a segment and an offset, and you'd be constantly doing slow segment register loads.