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
> 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
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
> 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
>
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
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
> 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
> 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
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
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
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
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
12 matches
Mail list logo
