New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

address order while stacking/un-stacking registers should be incrementing #132

jeras opened this Issue Jun 4, 2018 · 3 comments


None yet
3 participants
Copy link

jeras commented Jun 4, 2018

I noticed the stack is getting filled from the top down, and also read from the top down.
This can cause performance degradation on systems where memory access is faster for consecutive addresses then for non consecutive addresses.
On most complex systems access to consecutive addresses provides better performance then random access (memory access bursts).
And in general the order of addresses is assumed to be incrementing, not decrementing.
This is also the case for instruction memory, instructions are fetched with incrementing addresses.
On larger systems data cache hides this HW optimization by providing random access to the CPU core and bursts on the memory bus.
On embedded systems without caches this might not be the case.
In this post I explained how SRAM memory access was pipelined (speculatively reading the next address) to increase clock speeds on an embedded system.

The question is, would it be possible to reverse the order in which the stack is accessed?
I will not pretend I know exactly what a stack frame is, but it seems to me once the frame is created it could be populated in any order.
Others might know if there are other issues, for example with backwards compatibility.

The related code is here:
the variable offset should be properly initialized and then incremented for each register.
The same goes for the list of FP registers.

There might be other instances where an address counter is decremented instead of incremented, but this is common practice only for stack pointers as far as I know.

Iztok Jeras

@wsong83 wsong83 referenced this issue Jun 6, 2018


2018-06-08 #81

6 of 9 tasks complete

This comment has been minimized.

Copy link

palmer-dabbelt commented Jun 7, 2018

This seems like a reasonable idea to me. If this gets added it should probably be added with some sort of tuning flag (maybe -mspill-stack-upwards) in case anyone else is building heuristics for the current stack behavior. Would you feel comfortable submitting a patch? If it passes the GCC test suite then I'd be happy accepting one, but I don't think we'll have time to produce it ourselves.


This comment has been minimized.

Copy link

jeras commented Jun 7, 2018

I am working on it, but it will take me some time to get the environment ready.


This comment has been minimized.

Copy link

jim-wilson commented Jun 7, 2018

Note that we can't accept a patch without an FSF copyright assignment, which may be easy or difficult to get, depending on where you work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment