Marco V

(Free Pascal started life as a Turbo Pascal compatible compiler)

"Pascal calling convention" is a C foreign calling convention and unrelated to Pascal calling conventions (to be exact the Delphi register calling convention harks back to the Intel proposed CC for i686 and later). The fact that URL names 16-bit registers should have been a warning.

I'm in the same ballpark as Lars. Quite often these are toplevel handlers for tcp/udp ip/comport etc threads.

Corruption of the stack can mess up SEH I guess.

If you get a segmentation violation or something, you are doing something that is not allowed. Show some code.

The problem is that while that philosophy works well with reasonably clean languages that were designed top down using a grammar, it often doesn't work very well to retrofit to languages that weren't, or have seen decades worth of ad-hoc expansion with attempts at backwards compatibility. The delphi dialect is much more complicated then most people think. Note that if you get something working, you might want to try to push selected parts of the Free Pascal compiler test suite through it to iterate and harden the grammar against corner cases. But one of the problems of grammar driven solutions is that you need to duplicate many rules for each exception making the grammar unworkable at some point. Also, for something functional you often also need some form of semantic analysis, and Delphi has quite some implicit conversions (that then e.g. wreak havoc on e.g. overloading selection).

I have a handful of gotos in my code. Mostly they have this form if compare1 then begin if compare2 then ... else goto label1 end else .... label1: IOW jumping out of a multilevel IF block is faster than just letting it run its course. It is still active code, but I haven't revalidated the decision in ages (XE 1 or 3 times or so). Which is a problem with all low-level optimizations. The code searches for aggregates in an image (blob) so is quite RDS.

Peter: that generally still works as of Delphi Seattle, I use it regularly. But it might have unicode issues due to working over a pansichar buffer, which would cause corruption when unicodestring is converted to array of ansichar. There is some MBCS support in textrec too but I have no experience with it, and probably would require updating devin/out. As so often, a workaround for that could be setting the ansi codepage to UTF-8 per Windows 10-1805+ manifest, but that of course has very wide consequences. I don't have much experience with that in Delphi. Free Pascal has an unit of the same name and fucntion, but also supportsWriteStr(), which is available even in Delphi mode, so it is first order approx compatible with both Delphi and GPC for this.

Free Pascal has a Native NT target (so NOT win32 layer), and it can generate such binaries. IIRC there have been experiments with Delphi too, but then using binary converters. Anyway, in questions like this that is language vs language, it is IMHO confusing to pull in things that not every C compiler can do either.