Do arrays made by gcc grow downwards in x86

[clementttttttttt]

title.

[alexfru]

The plain old C/C++ arrays neither grow nor shrink.
If you allocate memory dynamically via malloc() and then realloc() it, the new pointer can be less than, equal to or greater than the old one (which you got from malloc()).
Not sure if that helps. Clarify the question if it doesn't.

[Solar]

As for order of elements, consider that &x[2] needs to be "two larger than" &x[0], so having them in reverse order would only complicate things unnecessarily.

But I, too, am intrigued. Why are you asking?

[alexfru]

But I, too, am intrigued. Why are you asking?

I wonder if it has anything to do with the x86 expand-up and expand-down segments.
But it would be odd to use those and the segmentation mechanism in general.

[iansjack]

There's a very simple way to answer this sort of question. Write a simple test program and inspect the assembler code produced by the compiler.

[bloodline]

There's a very simple way to answer this sort of question. Write a simple test program and inspect the assembler code produced by the compiler.

A person asking this sort of question probably won’t know x86 asm. A better approach would be to write a quick test program. Filling a small array with some known values, and the using pointer arithmetic to see if the array pointer -1, then -2, then -3, etc... returns the expected values.

I’m also intrigued as to why this question is being asked? Perhaps the poster is confusing arrays and stacks?

[iansjack]

I'm pretty sure that anyone posting on these forums has at least a passing acquaintance with x86 assembly language - or at least a desire to learn the basics.

But, in any case, how would such a person know whether decrementing a pointer value is moving upwards or downwards through RAM? If they understood arrays and pointer arithmetic then they wouldn't need to ask the question.

[Schol-R-LEA]

I'd like to hear why you ask as well, clementttttttttt. Could you describe the actual problem you are trying to solve?

My guess is that the real question is something along the lines, "how do I access a C-style format string (on the stack) from assembly", but that's just speculation. We'd really need to know what the OP is trying to accomplish, rather than what they are asking about, to to have any chance of helping.

EDIT
For the record: IIUC, string arguments are not stored on the stack, only pointers to the strings are (and even those might not be, depending on how the compiler optimizes the references and/or argument passing).

Constant strings (string literals and those string variables which were initialized with string literals when declared) are stored globally, usually in an .rodata section (which the paging mechanism will usually enforce by marking the mapped pages as read-only, but that would be up to your virtual memory manager), even if they are only visible locally within a given function.

Mutable global strings which are declared as a sized char array rather than initialized (which are fixed in size, but not in the data they contain) are in the global .data section.

Local mutable strings - which, remember, are just char arrays - are stored on the stack, but the array elements, like the fields of other data structures, go 'up' as far as I can tell, so that the pointer arithmetic is consistent.

For strings whose storage space is dynamically allocated, the data would be on the heap, and has to be explicitly freed when you no longer are using it (otherwise it causes a memory leak).

In all of these cases, they grow 'up' through memory, not down, no matter how the stack grows, i.e., my_array[1] is always higher in memory than my_array[0], my_array[2] is higher still, etc.

Comments and corrections welcome.

[clementttttttttt]

I had an idea of save register conveniently by moving esp to an array and dump the registers using pushad.

[alexfru]

I had an idea of save register conveniently by moving esp to an array and dump the registers using pushad.

Write an assembly routine and do just that, PUSHAD and pass ESP to a C function. If you make that C function return a new ESP value back to the assembly routine, you can conveniently switch context, not just save/restore.

[bloodline]

I had an idea of save register conveniently by moving esp to an array and dump the registers using pushad.

I’m guessing this is related to the other post you made recently about multitasking issues. I think really you should allocate sufficient RAM from your main memory pool, but that said an array is a legitimate way to reserve a known size of RAM, so you could dim an array:

Code: Select all

uint8_t myArray[128];    // a 128 byte array

Then find the address of the top of that array:

Code: Select all

void* arrayTop =(void*)&myArray[127];

Now use some inline assembly to load the value of the stackTop pointer into ESP (remember to save the value of ESP somewhere first!), then when you push registers they should fill the array top to bottom, as a stack.

Not sure how useful this is.

[Octocontrabass]

I had an idea of save register conveniently by moving esp to an array and dump the registers using pushad.

Why are you saving the registers? Is there anything else that might use the stack while you have ESP pointed to the array? How will you point ESP to the correct location afterwards?

Using the stack this way is pretty common on some 8-bit and 16-bit architectures, where stack operations can be simpler, faster, or smaller than ordinary register-to-memory moves. It's usually not simpler on x86, since there is no convenient register you could use to keep track of the stack location while you have ESP pointed elsewhere. It's usually not faster either, although that varies depending on the CPU. The size advantage is still there though!

Then find the address of the top of that array:

Code: Select all

void* arrayTop =(void*)&myArray[127];

You probably want &myArray[128] here, since the stack pointer must point past the end of the array in order to fill the array. (Or perhaps &myArray[32] since PUSHAD only writes 32 bytes.)

Now use some inline assembly to load the value of the stackTop pointer into ESP

Careful with that, GCC and Clang both assume you won't touch ESP in your inline assembly.

[bloodline]

Now use some inline assembly to load the value of the stackTop pointer into ESP

Careful with that, GCC and Clang both assume you won't touch ESP in your inline assembly.

I didn’t know that, but It makes sense given C’s reliance upon the stack! Perhaps we can advise @clementttttttttt to restore a valid ESP after he’s pushed the registers into his array.