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/
> 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 t
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
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 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 cur
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
> 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 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
> 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
> 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
> mo
10 matches
Mail list logo
