[fpc-pascal] Element type of set at compile time
Is there a compiler intrinsic to get the element type of a set at compile time? So if you have “set of T” it should return T. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
> On May 15, 2022, at 12:00 AM, Dennis Lee Bieber via fpc-pascal > wrote: > > Non-portable would be in-line assembly supporting "PUSH"/"PULL/POP" > operations on the stack. But would they be able to ensure the unwind works > properly? After all, one could POP data all the way back into the calling > functions stack frame. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 14-5-2022 17:51, Jonas Maebe via fpc-pascal wrote: On 14/05/2022 17:31, Marco van de Voort via fpc-pascal 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. 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 14/05/2022 17:31, Marco van de Voort via fpc-pascal 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 14-5-2022 10:49, Hairy Pixels via fpc-pascal 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 14/05/2022 16:37, Hairy Pixels via fpc-pascal 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 2022-05-14 10:52, Hairy Pixels via fpc-pascal wrote: 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? 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
> On May 14, 2022, at 1:03 PM, Michael Van Canneyt via fpc-pascal > wrote: > > 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. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On Sat, 14 May 2022, Hairy Pixels via fpc-pascal wrote: On May 13, 2022, at 11:08 PM, Michael Van Canneyt via fpc-pascal 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. Is alloca something which is part of the OS or can this be implemented by programmers or used from other libraries? 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.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] alloca
On 14/05/2022 07:45, Jonas Maebe via fpc-pascal wrote: On 14/05/2022 03:34, Hairy Pixels via fpc-pascal wrote: On May 13, 2022, at 11:08 PM, Michael Van Canneyt via fpc-pascal wrote: Is there an “alloca" like function in the RTL which allocates memory from the stack? For examplehttps://man7.org/linux/man-pages/man3/alloca.3.html No such function exists in FPC. Is alloca something which is part of the OS or can this be implemented by programmers or used from other libraries? 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. It *requires* compiler support for... Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
