Is there an “alloca" like function in the RTL which allocates memory from the stack? For example https://man7.org/linux/man-pages/man3/alloca.3.html

Regards,
Ryan Joseph

Hairy Pixels wrote

Is there an “alloca" like function in the RTL which allocates memory from the stack? For example https://man7.org/linux/man-pages/man3/alloca.3.html

No such function exists in FPC.

Michael.

Is alloca something which is part of the OS or can this be implemented by programmers or used from other libraries?

Regards,
Ryan Joseph

It compiler support for the allocation to actually happen on the stack. When it's actually implemented in a library (rather than redirect to a compiler intrinsic via a C macro), it will generally just allocate on the heap instead.

Jonas

It *requires* compiler support for...

Jonas

As far as I can see, it can only be implemented in the compiler. Only the compiler knows how much stack it uses for a certain routine. the alloca needs to interact with this. FPC also has the nostackframe modifier, inline modifier: all things which in general interact with the stack.

The man page you refer to hints at this, it says the alloca function is compiler-dependent and machine-dependent. It names so many pitfalls that I would not recommend its use. If you think you need this, better declare an array of bytes of a sufficient size and use that.

Michael.

Apparently what it does is advance the stack pointer x bytes and return a pointer to the new location so you could probably do that with some assembly. Of course this is dangerous because you can request more memory than exists in the current frame.

The reason I wanted to try this was because I saw some C++ example where the overrode the new operator and used alloca instead of malloc (like overriding NewInstance in FPC) and I thought this would be an interesting solution for some classes and just a fun experiment to play with.

Regards,
Ryan Joseph

On May 14, 2022, at 1:01 PM, Jonas Maebe via fpc-pascal wrote: It *requires* compiler support for...

The RTL has get_frame but that just tells you the start of the frame right? If you had the stack pointer address you could advance that pointer x bytes and get a new location in the stack?

Regards,
Ryan Joseph

No, because most modern OSes don't allow you to address memory below the stack pointer (and for the ones that do to a limited extent, the compiler could be using that memory already).

Jonas

On May 14, 2022, at 4:04 PM, Jonas Maebe via fpc-pascal wrote: No, because most modern OSes don't allow you to address memory below the stack pointer (and for the ones that do to a limited extent, the compiler could be using that memory already).

I thought the stack had a fixed size of memory that’s in every frame and it’s just a matter of if it’s occupied by any local variables or not. Seems conceptually simple to advance the pointer as if a local variable was declared but maybe this needs to happen at compile time making alloca more of a compiler intrinsic.

Regards,
Ryan Joseph

Hairy Pixels wrote

> On May 14, 2022, at 4:04 PM, Jonas Maebe via fpc-pascal wrote: > > No, because most modern OSes don't allow you to address memory below the stack pointer (and for the ones that do to a limited extent, the compiler could be using that memory already). I thought the stack had a fixed size of memory that’s in every frame and it’s just a matter of if it’s occupied by any local variables or not. Seems conceptually simple to advance the pointer as if a local variable was declared but maybe this needs to happen at compile time making alloca more of a compiler intrinsic.

Only the part between the current address in the stack pointer register and the base of the stack when the program started is valid to address (barring some minor exceptions). The stack pointer register gets adjusted by the compiler any time the stack needs to grow or shrink, which indeed generally mostly happens on function entry/exit.

Jonas

Hairy Pixels wrote

Apparently what it does is advance the stack pointer x bytes and return a pointer to the new location so you could probably do that with some assembly. Of course this is dangerous because you can request more memory than exists in the current frame.

But optimizations sometimes eliminate the frame pointer and use the stackpointer directly to index e.g. local vars and params. Also when an exception happens, the stack pointer is not as expected in exception frames (don't know if that really is an issue, but I can image).  It would be interesting how C handles this (e.g. exceptions while alloca called in a loop?)

So the only non hacky way is to implement support in the compiler I think.

Marco van de Voort wrote

Also when an exception happens, the stack pointer is not as expected in exception frames (don't know if that really is an issue, but I can image).  It would be interesting how C handles this (e.g. exceptions while alloca called in a loop?)

This is handled via dwarf call frame information, which is also generated by the compiler. It describes how to restore the stack pointer for every instruction address where it changes.

Jonas

I was thinking about SEH, but same principle. But that is exactly what I expected, so if you manually mutate the stack pointer using assembler, it won't register in the unwind info frames.

Hairy Pixels via fpc-pascal said on Fri, 13 May 2022 22:43:15 +0700

Is there an “alloca" like function in the RTL which allocates memory from the stack? For example https://man7.org/linux/man-pages/man3/alloca.3.html

Why not just allocate from the heap? Everything I've seen tells me that if you want a variable with memory from the stack, you just declare it and it's valid throughout the procedure or function in which it's declared, and gets reused when you go out of scope (no need to free).

SteveT

Steve Litt
March 2022 featured book: Making Mental Models: Advanced Edition http://www.troubleshooters.com/mmm

If you know how to make a simple proof of concept I’d be curious to test it. I remember when I was talking about coroutines some time back I found this (http://www.festra.com/wwwboard/messages/12775.html) which does some stack pushing/popping or stack variables.

As an side, does the inline assembly in FPC work on arm64 or is it Intel only?

Regards,
Ryan Joseph