question(s) about compilerproc lazarus / 62-General ---------------------------------------------------------------------- 440bx · 2022-09-25 02:54 Hello, I was looking at disassemblies of FPC executables and noticed that some functions/procedures were very nicely implemented... by that I mean, noticeably better/tighter/faster than the code the compiler produces for a user-written function. An example among many of such a function/procedure is fpc_widechar_length.  Looking in the source code, I see that this function is declared as "compilerproc".  Looking around for documentation on the "compilerproc" directive didn't produce informative results. I copy/pasted the function's code into my own little test program and to my disappointment the code the compiler generated for my "local" copy of the function was nowhere near as tight and fast as the one that is part of the rtl even though it is the same code. My question is: what do I have to do to get the same - nice and tight - code the compiler generated for the rtl ? (no stack frame, everything in registers and nothing moved in and out of the stack) Also, is there some documentation on "compilerproc" (and "rtlproc" which is another one I ran into) ? Thank you for your help. ---------------------------------------------------------------------- Thaddy · 2022-09-25 07:02 These are documented in system.fpd which is not compilable, but shows the compilerprocs. Note the efficiency is because of the compiler itself. ---------------------------------------------------------------------- Jonas Maebe · 2022-09-25 07:19 The compilerproc directive does not affect code generation. The rtl does contain handcrafted assembly implementations of that particular function for several architectures though. ---------------------------------------------------------------------- 440bx · 2022-09-25 11:03 Thank you Thaddy and Jonas. What is it that "compilerproc" informs the compiler about and what does it cause it to do ?  IOW, what's the difference between a "compilerproc" function/procedure and one that is not ? ---------------------------------------------------------------------- Jonas Maebe · 2022-09-25 14:02 The main thing it does is make it impossible to call the procedure manually, because its symbol gets hidden at the Pascal level. ---------------------------------------------------------------------- 440bx · 2022-09-25 14:25 Quote from: Jonas Maebe on September 25, 2022, 04:02:21 pmThe main thing it does is make it impossible to call the procedure manually, because its symbol gets hidden at the Pascal level. good thing to know... thank you Jonas. ---------------------------------------------------------------------- PascalDragon · 2022-09-25 19:21 Quote from: 440bx on September 25, 2022, 01:03:31 pmWhat is it that "compilerproc" informs the compiler about and what does it cause it to do ?  IOW, what's the difference between a "compilerproc" function/procedure and one that is not ? In addition to what Jonas wrote: that directive is used for functions that are called by the compiler directly without them being part of a call from some user code, because they are necessary to implement some language functionality (to avoid having to implement that functionality inside the compiler). ---------------------------------------------------------------------- 440bx · 2022-09-25 20:07 Quote from: PascalDragon on September 25, 2022, 09:21:31 pmthat directive is used for functions that are called by the compiler directly without them being part of a call from some user code, Thank you PascalDragon for the additional information.  I don't see what "functions that are called by the compiler directly without them being part of a call from some user code" means.  Aren't all functions called "directly" whether it's by a compiler ("FPC" in this case) or any other program ?. The only guess I can think of is that "compilerproc" functions/procedures are part of the set of functions/procedures that make up the core set of functions the compiler needs to be already present (pre-existing/pre-implemented) in order to compile itself.  Am I on the right track here ? ---------------------------------------------------------------------- PascalDragon · 2022-09-26 11:41 Quote from: 440bx on September 25, 2022, 10:07:16 pmQuote from: PascalDragon on September 25, 2022, 09:21:31 pmthat directive is used for functions that are called by the compiler directly without them being part of a call from some user code, Thank you PascalDragon for the additional information.  I don't see what "functions that are called by the compiler directly without them being part of a call from some user code" means.  Aren't all functions called "directly" whether it's by a compiler ("FPC" in this case) or any other program ?. In essence, yes, but what I mean that these function calls aren't visible as is in the source. Take WriteLn for example: in your source there'll be a WriteLn('Hello World') call, but in the end it's a sequence of fpc_get_output, fpc_write_text_shortstr (or fpc_write_text_ansistr or fpc_write_text_unistr), fpc_iocheck and fpc_writeln_end all of which are marked as compilerproc (and all of which don't have a mangled name). And this is not achieved by inlining something, but by the compiler directly emitting suitable calls. Quote from: 440bx on September 25, 2022, 10:07:16 pmThe only guess I can think of is that "compilerproc" functions/procedures are part of the set of functions/procedures that make up the core set of functions the compiler needs to be already present (pre-existing/pre- implemented) in order to compile itself.  Am I on the right track here ? No, these are just core functions which back some of the core intrinsics. The compiler itself is a normal Pascal application that requires quite a lot more of the RTL. ---------------------------------------------------------------------- 440bx · 2022-09-26 12:04 Thank you for the additional info PascalDragon.  I think I'm getting the "gist" as to the reason for these compilerproc(s).