[fpc-devel] Little question about the

[J. Gareth Moreton]

 Thanks Sven,
 Sorry if I'm bringing up obvious points.  I've set "pure" to be
interface-only - it's a little tricky because if you now specify it in the
main source file, it says that it can't be used in the implementation
section, even though, really, the main file doesn't have such section. 
Still, that can be dealt with.
 This will require a lot of testing once I start submitting patches!

 Gareth aka. Kit

 On Fri 10/08/18 06:45 , "Sven Barth" pascaldragon at googlemail.com sent:
 Gareth sent me the following two mails in private, but they were ment 
 for the list: 

 Am 09.08.2018 um 16:18 schrieb J. Gareth Moreton: 
 > Thanks Sven. Normally I would agree with 
 > "pure" only belonging in the interface 
 > section, but it causes problems when you 
 > try to put a pure function inside the main 
 > program block, as the entire thing is 
 > considered equivalent to implementation. 
 > Also, inline is allowed in the 
 > implementation section, and the two follow 
 > similar rules in regards to their calls 
 > being modified. 
 > 
 > Just to clarify, "pure" doesn't change 
 > anything in regards to the parameter types 
 > or how a call with variable arguments is 
 > handled. The raw signature shouldn't 
 > change. It's an optimisation hint. At 
 > least it is in a perfect world! 

 Am 09.08.2018 um 23:10 schrieb J. Gareth Moreton: 
 > I asked the question because I stumbled across something interesting.  
 > I've been using the following set of functions to see how the compiler 
 > handles things that are a bit out of order (using 'inline' as a 
 > temporary stand-in): 
 > 
 > program PureTest; 
 > 
 > function PureMax(const a: Double; const b: Double): Double; forward; 
 > 
 > procedure TestFunc; 
 > begin 
 >   WriteLn(PureMax(2.0, 3.0)); 
 > end; 
 > 
 > function PureMax(const a: Double; const b: Double): Double; inline; 
 > begin 
 >   if (a > b) then 
 >     Result := a 
 >   else 
 >     Result := b; 
 > end; 
 > 
 > begin 
 >   TestFunc; 
 > end. 
 > 
 > **** 
 > 
 > Turns out, to my surprise, after analysing the nodes and the 
 > disassembly, that "PureMax" is not inlined inside the TestFunc 
 > routine.  I haven't tested units yet, but would a similar situation 
 > occur if a function is not defined as inline in the "interface" 
 > section and only the "implementation" section (unless the caller 
 > appears after said function in the source file)? 
 > 
 > Either way, I'm leaning towards making the new "pure" directive an 
 > interface-only directive as Sven suggested, as that will make things a 
 > lot easier if a pure function is used as part of a constant 
 > definition.  After all, "pure" would have a bit more of a notable 
 > effect than "inline" because it dictates where the function can and 
 > cannot be used. 

 I hadn't thought that I need to explain that, but apparantly you haven't 
 yet reached that far in your research of the compiler, so: 
 - of course I only mean that it's an interface-only modifier if there 
 *is* an interface section; routines that are - inside a unit - only 
 declared inside the implementation section are obviously exempt from 
 this (thus also for the program file) 
 - again I wrote that I don't mean that "pure" modifies the parameters, 
 but it modifies the meta data (most importantly checksum) of the 
 interface section when you add a modifier flag inside the implementation 
 section. The compiler first handles the interface sections of units and 
 might then compile interface sections or even implementation sections of 
 other units depending on the dependencies between the units. If a flag 
 only appears in the implementation section than this messes up this 
 whole thing as the other units would need to be recompiled. This is 
 already a mess with "inline" so we don't need to do that with "pure" as 
 well, especially as we don't need to be Delphi compatible here. 
 - yes, it is correct that the compiler's capability to inline depends on 
 the order of the routine definitions. The compiler generates the code 
 routine by routine so if the routine's body has not yet been encountered 
 then it can't be inlined. (When using generic specializations it 
 triggeres the generation of the specialized routine bodies before 
 generating the routine to avoid "inline" not working for generics) For 
 "pure" we can even go so far as to say that a routine body *must* be 
 available to be able to call it inside another "pure" routine. 
 Everything else would be an error. 

 I hope this clears things up a bit. 

 Regards, 
 Sven 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180810/c6c9ad25/attachment.html>