Thanks - I'll take a look to see if it's usable. Otherwise, any float128 type
would probably be called "Quadruple" if we're going by the naming convention
used
in Object Pascal and Visual Basic, for example.
Gareth
On Wed 11/07/18 17:54 , "Sven Barth" pascaldra...@googlemail.com sent:
> J.
J. Gareth Moreton schrieb am Mi., 11. Juli
2018, 15:13:
> float128 does sound like a good solution
> overall. I'm not sure where to begin with
> that though, or even what to call it for
> Pascal, since "float128" is distinctly C-
> like! It could be something to put on my
> list of possible
Compile-time evaluation will always be a
performance hit for the compiler
unfortunately, even for the simplest of
algorithms, which is why I feel that only
those functions that the programmer says
are pure should be evaluated. If anyone
has ideas for performance enhancements
though, feel
Tue, 10 Jul 2018 03:36:01 +1000 Thorsten Engler wrote:
>> -Original Message-
>> From: fpc-devel On Behalf Of
>> Max Nazhalov via fpc-devel
>> Sent: Tuesday, 10 July 2018 02:25
>>
>> Just one question: doesn't all this new stuff introduce another kind
>> of mess during cross-compiling?
On Mon 09/07/18 22:39 , "Bart" bartjun...@gmail.com sent:
> On Mon, Jul 9, 2018 at 6:59 PM, J. Gareth Moreton
>
> e...@moreton-family.com> wrote:
>
>
> > out, not least because the answer will cause an
> overflow (e.g. the result of
> > A(4,2) has almost 20,000 decimal digits and,
> naïvely,
On Mon 09/07/18 20:53 , wkitt...@windstream.net sent:
>
>
>
>
> sorry for this off-topic post but are you aware that your messages are not
>
> threading into the topic under discussion? every one of your posts looks
> like a
> separate thread and there's nothing to link it to the message
On Mon, Jul 9, 2018 at 6:59 PM, J. Gareth Moreton
wrote:
> out, not least because the answer will cause an overflow (e.g. the result of
> A(4,2) has almost 20,000 decimal digits and, naïvely, takes longer than the
> age
> of the Universe to compute).
Ackerman(4,2) = (2^65536) - 3 (it's
sorry for this off-topic post but are you aware that your messages are not
threading into the topic under discussion? every one of your posts looks like a
separate thread and there's nothing to link it to the message you are actually
responding to... looking at them, there's no references
Am 09.07.2018 um 18:24 schrieb Max Nazhalov via fpc-devel:
Just one question: doesn't all this new stuff introduce another kind
of mess during cross-compiling?
E.g. some complex nested const.expr. "sin(cos(0.12345))" evaluated by
the compiler on x64 (double precision) is not the same as if it
The intention is to perform the analysis of pure functions at the
pre-compilation
stage where all the Pascal code is transmuted into nodes, which are
platform-independent and also have the advantage of not requiring total
rebuilding of a project, since it is these nodes that are stored in PPU
> -Original Message-
> From: fpc-devel On Behalf Of
> Max Nazhalov via fpc-devel
> Sent: Tuesday, 10 July 2018 02:25
>
> Just one question: doesn't all this new stuff introduce another kind
> of mess during cross-compiling?
>
> E.g. some complex nested const.expr. "sin(cos(0.12345))"
Admittedly I have slightly selfish reasons for my proposed improvements. I like
to play around with mathematical programming where loops can run for several
days
or weeks, so even the slimmest of savings adds up to a lot of saved time... and
I
love Object Pascal! Granted I can use assembly
Just one question: doesn't all this new stuff introduce another kind
of mess during cross-compiling?
E.g. some complex nested const.expr. "sin(cos(0.12345))" evaluated by
the compiler on x64 (double precision) is not the same as if it would
be evaluated by the compiled program itself running on
> On Jul 9, 2018, at 3:25 AM, Sven Barth via fpc-devel
> wrote:
>
> It would allow you to declare constants that use those functions with the
> compiler evaluating them at compile time.
That’s a double win then. Very good idea this is.
Regards,
Ryan Joseph
On Sun, Jul 8, 2018 at 4:43 PM, Thorsten Engler wrote:
>> -Original Message-
>> From: fpc-devel On Behalf Of
>> R0b0t1
>> Sent: Monday, 9 July 2018 07:22
>>
>> There were some other comments touching on reasons for or against a
>> keyword, and I apologize for not speaking to them
I meant to say tan(Pi / 4) in that
example. Sorry. Trying to assign tan(Pi /
2) to something will probably cause an
error, or at the very least be an
interesting test case, because the result
is undefined.
Gareth aka. Kit
On Mon 09/07/18 12:00 , "J. Gareth
Moreton"
Besides being able to assign the function
result to constants, the main benefit is
that, for constant inputs, the result is
deterministic and so the compiler can
calculate this beforehand and replace a
function call with an assignment. For
example, if tan was a regular function, x
:= tan(Pi
Ryan Joseph schrieb am Mo., 9. Juli 2018,
08:45:
>
>
> > On Jul 8, 2018, at 8:50 AM, J. Gareth Moreton
> wrote:
> >
> > With some blessing from Florian on the concept, I've set up a Wiki page
> discussing the design proposals for the support of pure functions, as well
> as some explanation on
> On Jul 8, 2018, at 10:55 AM, Marco van de Voort wrote:
>
> It doesn't explain why you chose for a modifier rather than preprocessor
> switch.
Performance aside I think it’s useful to mark a function as “pure” so you can
guarantee it’s not messing with global state. I’m sure I could have
> On Jul 8, 2018, at 8:50 AM, J. Gareth Moreton
> wrote:
>
> With some blessing from Florian on the concept, I've set up a Wiki page
> discussing the design proposals for the support of pure functions, as well as
> some explanation on what they actually are.
>
What are the performance
I've only really researched and improved the peephole optimizer, which is
the assembler stage. I'm not sure how much optimisation is done at
earlier stages, but I do know that care is taken in deciding the best
implementation of a case block, for example, evaluating factors such as how
many
That's something for future research. Initially I just want to get pure
Pascal procedures working, and that's the most important since it's
cross-platform. Analysing assembler routines will require a different
kind of interpretation, and it will likely involve only allowing a certain
subset of
On Sun, Jul 8, 2018 at 8:15 PM, J. Gareth Moreton wrote:
> Yes, if any parameters are variables, then the function is not evaluated.
> My intention is that the purity of a function is only determined when it
> comes to evaluating it in an expression, but because of how complex
> functions can
On Sun, Jul 8, 2018 at 9:47 PM, Thorsten Engler
wrote:
>
>
> If the loop is being unrolled, what looks like a non-const expression
> becomes a const expression. So if SomeFunc is marked as pure, the compiler
> might be able to omit the call completely.
>
>
There were some time testing done with
to omit the call completely.
From: fpc-devel On Behalf Of J. Gareth
Moreton
Sent: Monday, 9 July 2018 10:15
To: FPC developers' list
Subject: Re: [fpc-devel] Pure function Wiki page
If I had to give a realistic example of a pure function in such a conditional
expression, how about
If I had to give a realistic example of a pure function in such a
conditional expression, how about?
"if (decay_constant * time_elapsed) >= ln(2) then ..."
This is a formula related to radioactive decay - if the condition is true,
then over half of the original sample has decayed (i.e.
On Sun, Jul 8, 2018 at 7:18 PM, Thorsten Engler
wrote:
> Maybe you don’t understand what “determine the purity of a function” means?
>
>
>
> It means that every time any function is called, the compiler has to try
> to execute the function at compile time (by working through the nodes like
> an
The problem with determining if a function is pure or not is not just
limited to looking for references to external memory and the like, but also
has to take into account that the function might contain an infinite loop,
for example, and this is difficult because there is no general-purpose
rary identifiers can NOT occur.
From: fpc-devel On Behalf Of Dmitry Boyarintsev
Sent: Monday, 9 July 2018 09:00
To: FPC developers' list
Subject: Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 6:47 PM, Thorsten Engler wrote:
You are thinking about something like:
const
context in which it can occur (and is checked for) is one in which
arbitrary identifiers can NOT occur.
From: fpc-devel On Behalf Of Dmitry
Boyarintsev
Sent: Monday, 9 July 2018 09:00
To: FPC developers' list
Subject: Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 6:47 PM
On Sun, Jul 8, 2018 at 6:47 PM, Thorsten Engler
wrote:
> You are thinking about something like:
>
>
>
> const
>
> x = FunctionCall(42);
>
>
>
> In which case, yes, the compiler could possibly see that as in implicit
> “check if that function is pure”.
>
>
>
> But “constant expressions” can
ure) it would fail right away.
From: fpc-devel On Behalf Of Dmitry
Boyarintsev
Sent: Monday, 9 July 2018 08:39
To: FPC developers' list
Subject: Re: [fpc-devel] Pure function Wiki page
On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote:
People kee
On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler
wrote:
> People keep talking about keywords. As shown in the examples, pure is not
> a keyword. It's a context-sensitive directive. This is already wrongly
> stated in the proposal itself (so people can be excused for picking up on
> the use of the
That's my fault for using the wrong
terminology in that case - feel free to
fix it.
And yes, the directive tells the compiler
that the programmer intends for this
function to be pure. It still requires
effort by the compiler to determine if
it's eligible, because the only way to
figure out
> -Original Message-
> From: fpc-devel On Behalf Of
> R0b0t1
> Sent: Monday, 9 July 2018 07:22
>
> There were some other comments touching on reasons for or against a
> keyword, and I apologize for not speaking to them precisely. But,
> this is why I would like to avoid a keyword - it is
On Sun, Jul 8, 2018 at 12:33 PM, Marco van de Voort wrote:
> In our previous episode, Florian Kl?mpfl said:
>> >
>> > It doesn't explain why you chose for a modifier rather than preprocessor
>> > switch.
>>
>> Why a preprocessor switch for something which applies to a particular
>> function?
>
>
Am 08.07.2018 um 19:33 schrieb Marco van de Voort:
In our previous episode, Florian Kl?mpfl said:
It doesn't explain why you chose for a modifier rather than preprocessor
switch.
Why a preprocessor switch for something which applies to a particular function?
Maybe. But this kind of stuff
On Sun, Jul 8, 2018 at 1:01 PM, Florian Klämpfl
wrote:
>
>
> No. Because pure is part of the function header and tells users "you can
> use this function with constant arguments in constant expressions and this
> won't change without notification". If the compiler determines by itself if
> a
On 08/07/2018 19:22, J. Gareth Moreton wrote:
At the same time, I would argue that, really, the programmer should
code something like this:
c := sin(x);
if c > y then b := c;
There probably isn't any harm in supporting such optimisation though.
Talking about this Maybe it is worth to
At the same time, I would argue that, really, the programmer should code
something like this:
c := sin(x);if c > y then b := c;
There probably isn't any harm in supporting such optimisation though.
Gareth
On Sun 08/07/18 18:19 , "J. Gareth Moreton" gar...@moreton-family.com
sent:
The
The concept of pure functions is that it allows for their evaluation at
compile time for constant arguments. In your example, function purity
wouldn't play into it because x, I assume, is a variable whose value is
unknown at compile time. However, advanced data flow analysis might be
able to
On 08/07/2018 16:50, J. Gareth Moreton wrote:
Hi everyone,
With some blessing from Florian on the concept, I've set up a Wiki
page discussing the design proposals for the support of pure
functions, as well as some explanation on what they actually are.
wiki.freepascal.org/Pure_functions
I
It's sort of the other way around. The lack of the directive implies the
function is impure, and so the compiler won't bother with any kind of
purity check. The presence of "pure" slows down the compiler, but
possibly producing much more efficient code. Because pure functions will
be rare, it
In our previous episode, Florian Kl?mpfl said:
> >
> > It doesn't explain why you chose for a modifier rather than preprocessor
> > switch.
>
> Why a preprocessor switch for something which applies to a particular
> function?
Maybe. But this kind of stuff will be rare, and is only an hint to
It also feels safer and more intuitive for the programmer. If you're
writing code such as "const Partitions = log2(Length(StaticList));"
(assuming Length(StaticList) evaluates to a constant value), then defining
log2 as a pure function shows you know what you're doing, because otherwise
it might
What Florian said. Only particular functions can be pure, and even if they
are marked as such, the compiler has to make sure they are fulfil a strict
set of criteria that requires a degree of data flow analysis, and this can
quickly take far too long to complete, especially if the function
Am 08.07.2018 um 18:53 schrieb Dmitry Boyarintsev:
On Sun, Jul 8, 2018 at 11:20 AM, J. Gareth Moreton mailto:gar...@moreton-family.com>> wrote:
As far as I know, keywords are often used (e.g. "constexpr" in C++). My
reasons are explained in the Wiki topic,
but it boils down to
Am 08.07.2018 um 18:55 schrieb Marco van de Voort:
In our previous episode, J. Gareth Moreton said:
wiki.freepascal.org/Pure_functions
I hope it proves useful to explain what I'm doing. How do the proposals
look so far, Florian?
It doesn't explain why you chose for a modifier rather than
In our previous episode, J. Gareth Moreton said:
> wiki.freepascal.org/Pure_functions
> I hope it proves useful to explain what I'm doing. How do the proposals
> look so far, Florian?
It doesn't explain why you chose for a modifier rather than preprocessor
switch.
On Sun, Jul 8, 2018 at 11:20 AM, J. Gareth Moreton <
gar...@moreton-family.com> wrote:
> As far as I know, keywords are often used (e.g. "constexpr" in C++). My
> reasons are explained in the Wiki topic, but it boils down to compiler
> performance.
>
How about adding a new modeswitch instead
As far as I know, keywords are often used (e.g. "constexpr" in C++). My
reasons are explained in the Wiki topic, but it boils down to compiler
performance. If every function is assumed to be pure, then the compiler
has to check each time if that is actually the case, and with a large
project
On Sun, Jul 8, 2018 at 9:50 AM, J. Gareth Moreton
wrote:
> Hi everyone,
>
> With some blessing from Florian on the concept, I've set up a Wiki page
> discussing the design proposals for the support of pure functions, as well
> as some explanation on what they actually are.
>
>
Hi everyone,
With some blessing from Florian on the concept, I've set up a Wiki page
discussing the design proposals for the support of pure functions, as well
as some explanation on what they actually are.
wiki.freepascal.org/Pure_functions
I hope it proves useful to explain what I'm doing.
53 matches
Mail list logo
