Jonas Maebe wrote:
Couldn't the framepointer be last parameter in all modes ?
That would still require some ugly hacks inside the parameter passing
code, because of the fact that on x86 the callee removes the parameters
from the stack and not the caller (so you'd still need a check
[EMAIL PROTECTED] wrote:
Let me add some more thoughts about procedural types:
- I like the ability to declare procedural types, the ISO convention
looks like one of the many incredible C hacks to me :-(
But it is standard pascal. And we need to support those zillion lines of
code
On 17 mrt 2005, at 00:06, Olle Raab wrote:
But the framepointer parameter must then be the last. That will make
macpas local procedures incompatible with the current code where it
is
passed as the first parameter.
Couldn't the framepointer be last parameter in all modes ?
That would still
On 14 mrt 2005, at 12:15, [EMAIL PROTECTED] wrote:
Example Powerpc with static link first:
local
static link r3
param no 1 r4
...
global
param no 1 r3
...
To avoid this problem, it would be better to have the static link last.
That won't work on x86 when the static
On 16 mrt 2005, at 17:42, Adriaan van Os wrote:
That won't work on x86 when the static link would be on the stack,
because there the callee removes the parameters from the stack (so if
it's a global function, it will remove sizeof(pointer) bytes too
little from the stack.
On x86, you can
That won't work on x86 when the static link would be on the stack,
because there the callee removes the parameters from the stack (so if
it's a global function, it will remove sizeof(pointer) bytes too
little from the stack.
On x86, you can generate code that checks the static link pointer
On 16 Mar 2005, at 21:46, Peter Vreman wrote:
Then you can do it just as well on ppc and other processors, but the
point of the trick was to avoid having to do this. Implementing this
sort of hacks will complicate the code generator (I'm not even
immediately sure how it would be implemented).
This
On 16 Mar 2005, at 21:46, Peter Vreman wrote:
Then you can do it just as well on ppc and other processors, but the
point of the trick was to avoid having to do this. Implementing this
sort of hacks will complicate the code generator (I'm not even
immediately sure how it would be
05-03-16 23.08, skrev Peter Vreman följande:
But the framepointer parameter must then be the last. That will make
macpas local procedures incompatible with the current code where it is
passed as the first parameter.
Couldn't the framepointer be last parameter in all modes ?
Things like
05-03-16 23.08, skrev Peter Vreman följande:
But the framepointer parameter must then be the last. That will make
macpas local procedures incompatible with the current code where it is
passed as the first parameter.
Couldn't the framepointer be last parameter in all modes ?
That will
Michael Van Canneyt wrote:
1. What happens if f would use a variable from somefun, and f is called
when somefun is no longer executed ?
This can not happen when the function parameter cannot be stored
anywhere.
2. I see no difference whatsoever between typ_fun and iso_fun, except
On Mon, 14 Mar 2005, Adriaan van Os wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure typ_fun( pf: tfun);
begin
end;
On 14 mrt 2005, at 09:45, Michael Van Canneyt wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure typ_fun( pf: tfun);
begin
On Mon, 14 Mar 2005, Jonas Maebe wrote:
On 14 mrt 2005, at 09:45, Michael Van Canneyt wrote:
7. Consider the following program:
program func;
type tfun = function( x: real): real;
procedure iso_fun( function f( x: real): real);
begin
end;
procedure
On 14 mrt 2005, at 10:15, Michael Van Canneyt wrote:
It seems to me that the following is perfectly valid code :
Var
StoredF : Function (x : real) : real
This is a regular procedural variable, not an ISO-style procedural
variable. Just like var a: array of byte; is a dynamic array and not
an
On 14 mrt 2005, at 10:37, [EMAIL PROTECTED] wrote:
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is
allowed,
the other should be allowed as
On 14 mrt 2005, at 10:34, Marco van de Voort wrote:
BuIt seems to me that the following is perfectly valid code :
Var
StoredF : Function (x : real) : real
This is not allowed. Only TP style is allowed with VAR, so
var stored : TSomeFunc;
That's not true, the above is perfectly valid (but it
On 14 mrt 2005, at 10:51, Michael Van Canneyt wrote:
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is
allowed,
the other should be allowed
Michael Van Canneyt wrote:
In fact standard pascal does not allow procedure variables, only
procedure
parameters (note the difference). I suppose the above problem is the
reason.
Then I think standard pascal is very handicapped indeed.
var
f : function : longint of procedure(a :
On 14 mrt 2005, at 10:34, Marco van de Voort wrote:
BuIt seems to me that the following is perfectly valid code :
Var
StoredF : Function (x : real) : real
This is not allowed. Only TP style is allowed with VAR, so
var stored : TSomeFunc;
That's not true, the above is
Procedure iso_fun( function f( x: real): real); begin
StoredF:=F;
end;
This assignment is invalid, it's the same as trying to assign a method
to a
regular procedural variable.
This is exactly my point: how does the compiler distinguish the two in
this case ?
Possible soultions: They
On 14 mrt 2005, at 10:51, Michael Van Canneyt wrote:
2. I see no difference whatsoever between typ_fun and iso_fun, except
the use of an extra type, which, in my opinion, does not change
anything to the usage or code of these functions. If one is
allowed,
the other should be
No, because in this case, you are comparing 2 basically different
programming
techniques: OOP and linear; they are fundamentally different in their
practical use.
The iso feature supports a third, namely recursive programming, which has
been forgotten after C took over the world and
Michael Van Canneyt wrote:
I will object against a solution that causes existing code to be altered
in any way, such as an extra hidden parameter for all callbacks. For the
ISO ones, I don't think there is any other way of doing it. As long as
it is
restricted to those, there is no problem...
If
On 14 mrt 2005, at 11:11, Michael Van Canneyt wrote:
No, because normally, one never mixes 'procedure of object' with
'procedural'.
You program either linear, either OOP, so you either use one or the
other,
never both. The distinction is also very clear.
Except when programming a compiler,
On 14 mrt 2005, at 11:53, Florian Klaempfl wrote:
I will object against a solution that causes existing code to be
altered
in any way, such as an extra hidden parameter for all callbacks. For
the
ISO ones, I don't think there is any other way of doing it. As long
as it is
restricted to those,
On Mon, 14 Mar 2005, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
I will object against a solution that causes existing code to be altered
in any way, such as an extra hidden parameter for all callbacks. For the
ISO ones, I don't think there is any other way of doing it. As long as it
is
On Mon, 14 Mar 2005, Jonas Maebe wrote:
On 14 mrt 2005, at 11:11, Michael Van Canneyt wrote:
No, because normally, one never mixes 'procedure of object' with
'procedural'.
You program either linear, either OOP, so you either use one or the other,
never both. The distinction is also very clear.
On 14 mrt 2005, at 11:58, Michael Van Canneyt wrote:
As far as I understood it, it would only be for ISO type i.e.
Function MyFunction (f : Func(X : Real) : Real) : Real;
begin
end;
If this is so, there is no problem.
It is, and those ISO types are additionally only allowed in MacPas mode
:) So
On 14 mrt 2005, at 11:11, [EMAIL PROTECTED] wrote:
I would only see the use of being able to pass a local function as a
callback
if the called function can be used for both local and global callback
procedures.
It can. When a global proc is passed, the static link is set to nil.
That is
With the above method, it should be relatively simple to implement
local procedures (functions) as procedural parameters, without
affecting the code generation of the current compiler.
The default calling convention is with registers. How do you want to
handle that? At beforehand from the
Adriaan van Os wrote:
1. On the todo list for fpc's MacPas mode is a feature that allows local
procedures (functions) to be passed a procedural parameters. I
tentatively put it on my own todo list, since this is the feature that I
like most in Pascal compilers, at the same time making a small
32 matches
Mail list logo
