So I got my salvaged code transferred over, now I'm mostly researching
the constant propagation and inlining code. I may have to make
adjustments to the constant propagation code so i can reuse it, so I can
introduce things like a node counter (to catch infinite loops) as well
as allow the
Maybe I've fallen into a trap of sunken cost fallacy or being too proud
of my own code rather than properly looking at what's already
available. Part of my fear with using the constant propagation code is
that it constantly copies and transforms the nodes every time the pure
function needs to
On 02/05/2020 20:27, J. Gareth Moreton wrote:
> Well, as I've found, there is no straightforward method to actually
> determine if a function is pure or not. For example, if it stumbles
> upon a procedural call, which may be itself (recursion), it doesn't
> immediately know if that call is to a
Well, as I've found, there is no straightforward method to actually
determine if a function is pure or not. For example, if it stumbles
upon a procedural call, which may be itself (recursion), it doesn't
immediately know if that call is to a procedure that is itself pure or
not. There are
Am 01.05.20 um 11:41 schrieb J. Gareth Moreton:
I'm still learning these things - bear with me! I'll get one set up
when I have something preliminary working.
At the moment I haven't been able to unite the constant propagation code
with my pure functions because they work in fundamentally
I'm still learning these things - bear with me! I'll get one set up
when I have something preliminary working.
At the moment I haven't been able to unite the constant propagation code
with my pure functions because they work in fundamentally different ways
- for inline functions constant
> On May 1, 2020, at 4:05 PM, J. Gareth Moreton
> wrote:
>
> Okay, I'll give that a try - do I need to post the entire FPC repository
> there with my changes, or just the diff/patch files?
It shows the diffs for you. Fork the FPC project on GitHub
(https://github.com/genericptr/freepascal)
Okay, I'll give that a try - do I need to post the entire FPC repository
there with my changes, or just the diff/patch files?
Gareth aka. Kit
On 01/05/2020 07:01, Ryan Joseph via fpc-devel wrote:
On May 1, 2020, at 6:46 AM, J. Gareth Moreton wrote:
Is there a good way to show you guys the
> On May 1, 2020, at 6:46 AM, J. Gareth Moreton
> wrote:
>
> Is there a good way to show you guys the work in progress and for you to make
> more informed comments on the design along with any bugs and shortcomings?
> I'm making progress with make a pure factorial function, but it's
Is there a good way to show you guys the work in progress and for you to
make more informed comments on the design along with any bugs and
shortcomings? I'm making progress with make a pure factorial function,
but it's nowhere near ready for general use.
Gareth aka. Kit
--
This email has
One problem I have been running into due to the use of TConstValue are
circular unit references - I've had to move some definitions to
different units to get around it.
Gareth aka. Kit
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I guess so. I'll see what I can do and if the constant propagation
system is good enough to be expanded. At the moment I'm trying to get
something to work, then build from there.
Gareth aka. Kit
On 30/04/2020 20:18, Sven Barth via fpc-devel wrote:
J. Gareth Moreton
J. Gareth Moreton schrieb am Do., 30. Apr.
2020, 17:07:
> Currently I'm not using the constant propagation code for the pure
> function feature, but after some refactoring down the line, hopefully
> they can be made to use the same code and hence improve both features
> drastically. Note that
Currently I'm not using the constant propagation code for the pure
function feature, but after some refactoring down the line, hopefully
they can be made to use the same code and hence improve both features
drastically. Note that my 'node emulation' feature for pure functions
doesn't
It's likely that this feature may go through several iterations before
we settle on some code that everyone is happy with. At the moment I'm
trying to design and develop a system that captures everything, like
propagating through nested or recursive calls and calling internal
functions that
On 30/04/2020 07:24, Sven Barth via fpc-devel wrote:
> Well, Jonas is right that if you have a node tree that only has constant
> nodes as inputs the tnode.simplify method should (in theory) be able to
> completely collapse that (under the assumption that this is also handled
> by call nodes and
Am 29.04.2020 um 23:59 schrieb J. Gareth Moreton:
I suppose node emulation would be equivalent to constant propagation.
I sense we might need to refactor things afterwards so the same code
can be reused for both purposes. My current design for the emulation
would introduce a new virtual
I'm glad we agree that one benefit of pure functions is loop-hoisting.
I call them pure functions because that's the technical name for them:
https://en.wikipedia.org/wiki/Pure_function - they're analogous to a
mathematical function. 'Read-only' sounds a little ambiguous to me and
not
On 29/04/2020 23:29, J. Gareth Moreton wrote:
> Pure functions are a slightly tricky one because there is a lot of
> overlap with inline functions and constant propagation, and yet there
> are concepts that aren't covered by either, such as 'promotion' of pure
> function calls outside of loops and
On 29/04/2020 23:15, Sven Barth via fpc-devel wrote:
> Assuming we want to have support for constant evaluation of functions
> (and I do admit that sometimes that is a really nice to have), I don't
> really see a way around marking such functions somehow, cause otherwise
> we'd have to store the
On 29/04/2020 22:15, Sven Barth via fpc-devel wrote:
Assuming we want to have support for constant evaluation of functions
(and I do admit that sometimes that is a really nice to have), I don't
really see a way around marking such functions somehow, cause
otherwise we'd have to store the node
Am 29.04.2020 um 22:51 schrieb Jonas Maebe:
On 29/04/2020 22:43, J. Gareth Moreton wrote:
So are you officially rejecting pure functions and my future work on
them in this form?
I'm just trying to say that there is already a (primitive) framework for
propagating constant values through
On 29/04/2020 22:43, J. Gareth Moreton wrote:
> So are you officially rejecting pure functions and my future work on
> them in this form?
I'm just trying to say that there is already a (primitive) framework for
propagating constant values through functions (in the optconstprop
unit), and also an
So are you officially rejecting pure functions and my future work on
them in this form?
Gareth aka. Kit
On 29/04/2020 21:40, Jonas Maebe wrote:
On 29/04/2020 22:08, J. Gareth Moreton wrote:
Constant propagation is only really beneficial for inline functions,
That is incorrect.
although
On 29/04/2020 22:08, J. Gareth Moreton wrote:
> Constant propagation is only really beneficial for inline functions,
That is incorrect.
> although there is some crossover with pure functions. I was more meaning
> a system of tracking and storing these constants, or rather how they
> manipulate
Constant propagation is only really beneficial for inline functions,
although there is some crossover with pure functions. I was more meaning
a system of tracking and storing these constants, or rather how they
manipulate variables throughout a pure function.
I've also found some annoying
On 29/04/2020 13:41, J. Gareth Moreton wrote:
> Thanks for the response. Yes, this is all inside the compiler.
> Basically I need a means to keep track of the internal state of a
> function as I step through the nodes (a process I call 'node
> emulation'), namely local variables, parameters (if
Hi Sven,
Thanks for the response. Yes, this is all inside the compiler.
Basically I need a means to keep track of the internal state of a
function as I step through the nodes (a process I call 'node
emulation'), namely local variables, parameters (if they're not const,
they're basically
Am 29.04.2020 um 00:31 schrieb J. Gareth Moreton:
Hi everyone,
I'm having a serious bash at developing pure functions for FPC now,
specifically 'node emulation' so it can step through a pure function
and compute output values. One of the small problems I'm trying to
solve is keeping track
Limiting pure functions to the definitions of constants severely limits
their usefulness, and programmers may just ignore them completely and
calculate their results by hand where needed (e.g. replacing ln(2) with
0.69 etc.). They're designed to replace entire function calls with
pre-calculated
On Sat, Aug 11, 2018 at 8:50 PM J. Gareth Moreton
wrote:
> How and when is the constant defined? Should such constructs be disallowed
> and constants only allowed to be declared in other units that use the unit
> that contains the pure functions in its interface section? What would be
> the
I'm still figuring bits and pieces out, but I've managed to change the
checks so the error that I listed in the last e-mail only appears for
forward-declared functions, not interface + implementation, since I believe
everything gets fully defined by the time the first pass comes along. I'm
still
32 matches
Mail list logo
