Forum > General

question(s) about compilerproc

(1/2) > >>

440bx:
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:
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:
The compilerproc directive does not affect code generation. The rtl does contain handcrafted assembly implementations of that particular function for several architectures though.

440bx:
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:
The main thing it does is make it impossible to call the procedure manually, because its symbol gets hidden at the Pascal level.

Navigation

[0] Message Index

[#] Next page

Go to full version