On 22 Jan 2012, at 11:04, Sven Barth wrote:
> Ah... inside the compiler's sources. I thought you meant "the compiler
> inserts calls to prefetch in specific situations". ^^
It can also do that, if you compile it with -dprefetchnext (at least if that
still works, it's been a long time since I i
On 22.01.2012 10:34, Florian Klämpfl wrote:
Am 22.01.2012 09:15, schrieb Sven Barth:
On 21.01.2012 15:12, Florian Klaempfl wrote:
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a
pointer
cache
Am 22.01.2012 09:15, schrieb Sven Barth:
> On 21.01.2012 15:12, Florian Klaempfl wrote:
>> Am 21.01.2012 14:25, schrieb Sven Barth:
>>> On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a
pointer
cache or simply want to try out
On 21.01.2012 15:12, Florian Klaempfl wrote:
Am 21.01.2012 14:25, schrieb Sven Barth:
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a pointer
cache or simply want to try out the effect of prefetching class pointers
then I challenge you
Am 21.01.2012 14:25, schrieb Sven Barth:
> On 20.01.2012 11:18, Skybuck Flying wrote:
>> Finally if you do believe prefetching is a good alternative to a pointer
>> cache or simply want to try out the effect of prefetching class pointers
>> then I challenge you to implement it in a experimental bra
On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a pointer
cache or simply want to try out the effect of prefetching class pointers
then I challenge you to implement it in a experimental branch of the
free pascal compiler, so the prefetch i
On 20 Jan 2012, at 11:18, Skybuck Flying wrote:
> Another more radical approach would be to insert the prefetch instructions
> into the computer program at runtime, but this would require self modifieing
> code and is probably way to futuristic/complex to program at this moment.
It doesn't req
-Original Message-
From: Florian Klämpfl
Sent: Wednesday, January 04, 2012 22:20
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Me
Marcos Douglas schrieb:
Just this morning I had to move some methods out of a class, so that they
could be used without an instance. IMO it's a bad idea to bind any
general-purpose identifier to an artificial container (namespace...).
Why?
Using an identifier (unit class object, or it) is bett
On Fri, Jan 6, 2012 at 7:55 AM, Hans-Peter Diettrich
wrote:
> Marcos Douglas schrieb:
>
>
>>> Delphi (now) provides Records with methods, but these lack inheritance.
>>> Why
>>> introduce such a crippled construct, when Objects can do the same and
>>> more
>>> (virtual methods...).
>>
>>
>> +1
>>
Marcos Douglas schrieb:
Delphi (now) provides Records with methods, but these lack inheritance. Why
introduce such a crippled construct, when Objects can do the same and more
(virtual methods...).
+1
But more about Object type, what do you think to use Object to group
routines instead of using
On Thu, Jan 5, 2012 at 8:03 AM, Hans-Peter Diettrich
wrote:
> Marcos Douglas schrieb:
>
>
>>> I don't see any reason why the Object type should be dropped. It's close
>>> to C++ objects, useful in porting code. It allows for static objects,
>>> e.g. in the stack, while TObject is bound to the heap
Am 05.01.2012 11:22, schrieb Michael Schnell:
On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented
differently in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
On 01/05/2012 12:44 PM, Marco van de Voort wrote:
Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ?
:-)
even more funny...
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailm
05.01.2012 16:12, Marco van de Voort пишет:
In our previous episode, Sergei Gorelkin said:
This is no longer correct, stack based objects are initialized and
finalized if necessary. There was indeed an issue with inheritance (if
both ancestor and descendant contain managed members, then member
In our previous episode, Sergei Gorelkin said:
> This is no longer correct, stack based objects are initialized and
> finalized if necessary. There was indeed an issue with inheritance (if
> both ancestor and descendant contain managed members, then members of
> ancestor were not handled), but I
In our previous episode, Sergei Gorelkin said:
> > Afaik stack based TP Objects are not initialized and thus not safe for
> > automated types. (I looked into upgrading TV with ansistring a few years
> > back)
> >
> This is no longer correct, stack based objects are initialized and finalized
> if n
05.01.2012 15:45, Marco van de Voort пишет:
In our previous episode, Sven Barth said:
Object instead Class?
They are basically similar to "records with methods" (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested
In our previous episode, Sven Barth said:
> > Object instead Class?
>
> They are basically similar to "records with methods" (which we now have
> as well...) if you use them directly (this means: not as pointer types):
> they are located on the stack and nested objects are part of the memory
>
In our previous episode, Michael Schnell said:
> > Better question: what common capabilitiers are implemented differently
> > in Object and TObject?
> The funny thing being that TObject is a class and not an Object :-)
Which tobject do you mean? Objpas.tobject (Delphi) or objects.tobject (TP) ?
:
Florian Klämpfl schrieb:
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer a
Marcos Douglas schrieb:
I don't see any reason why the Object type should be dropped. It's close
to C++ objects, useful in porting code. It allows for static objects,
e.g. in the stack, while TObject is bound to the heap (without tricks).
So, Object types is indicated only for compatibility?
I
On 01/04/2012 07:14 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented
differently in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
I once for some reason tried to compile TurboV
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
> Skybuck Flying schrieb:
>>
>>
>> -Original Message- From: Hans-Peter Diettrich
>> Sent: Tuesday, January 03, 2012 14:56
>> To: FPC developers' list
>> Subject: Re: [fpc-devel] Pointer cache
On Wed, Jan 4, 2012 at 3:03 PM, Hans-Peter Diettrich
wrote:
> Sven Barth schrieb:
>
>
>>> I thinking if the Object type will be deprecated in the future... I hope
>>> not.
>>
>>
>> As Free Pascal still writes on its flag that it is compatible to Turbo
>> Pascal I doubt that it will be deprecated (
Skybuck Flying schrieb:
-Original Message- From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
&quo
Sven Barth schrieb:
And, as somebody asked, what the advantages (performance?) using
Object instead Class?
They are basically similar to "records with methods" (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested
Sven Barth schrieb:
I thinking if the Object type will be deprecated in the future... I
hope not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be deprecated (also there is quite some code
in the compiler and also in some packages which us
Michael Schnell schrieb:
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
That makes *what* difference?
DoDi
___
Am 04.01.2012 14:51, schrieb Marcos Douglas:
I thinking if the Object type will be deprecated in the future... I hope
not.
As Free Pascal still writes on its flag that it is compatible to Turbo
Pascal I doubt that it will be deprecated (also there is quite some code in
the compiler and also in
On Wed, Jan 4, 2012 at 10:26 AM, Sven Barth wrote:
> Am 04.01.2012 13:33, schrieb Marcos Douglas:
>
>> Object type is (very) older than Class type and I don't think the core
>> team wanted some similarity between Object and Class types. Everybody
>> prefer classes so, the Object type was forgotten
On 12/30/2011 07:09 PM, Hans-Peter Diettrich wrote:
Better question: what common capabilitiers are implemented differently
in Object and TObject?
The funny thing being that TObject is a class and not an Object :-)
-Michael
___
fpc-devel maillist -
Am 04.01.2012 13:33, schrieb Marcos Douglas:
Object type is (very) older than Class type and I don't think the core
team wanted some similarity between Object and Class types. Everybody
prefer classes so, the Object type was forgotten.
It wasn't the core team who introduced the differences betw
On Tue, Jan 3, 2012 at 11:26 AM, Skybuck Flying wrote:
>
>
> -Original Message- From: Hans-Peter Diettrich
> Sent: Tuesday, January 03, 2012 14:56
> To: FPC developers' list
> Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
>
>
> Sky
-Original Message-
From: Hans-Peter Diettrich
Sent: Tuesday, January 03, 2012 14:56
To: FPC developers' list
Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
"
You can implement su
Skybuck Flying schrieb:
vValue := mDepth1.mDepth2.mDepth3.mValue;
You can implement such a funny hierarchy in any language. So what?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-dev
On Fri, Dec 30, 2011 at 3:09 PM, Hans-Peter Diettrich
wrote:
> Skybuck Flying schrieb:
>
>
>>> 2. Nested/delegated classes incur a pointer access penalty, the deeper
>>> the nesting the higher the penalty.
>>
>>
>> "
>> Why? Nested classes are not a problem in OPL, more in C++ (multiple
>> inherit
Something like this ;):
type
TDepth3 = class
public
mValue : integer;
constructor Create;
destructor Destroy; override;
end;
constructor TDepth3.Create;
begin
mValue := 666;
end;
destructor TDepth3.Destroy;
begin
end;
type
TDepth2 = class
public
mDepth3 : TDepth3;
constructor Create;
Skybuck Flying schrieb:
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
"
Why? Nested classes are not a problem in OPL, more in C++ (multiple
inheritance!).
"
Nested classes are a problem because of the pointer overhead.
For example
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
"
What's fast RAM?
"
That would be the CPU L1 cache ;)
2. Nested/delegated classes incur a pointer access penalty, the deeper the
nesting the higher the penalty.
"
Why? Nested classes are n
Skybuck Flying schrieb:
My assumptions for this idea are:
1. Pointers to classes are mostly stored on the heap, in slow RAM.
What's fast RAM?
2. Nested/delegated classes incur a pointer access penalty, the deeper
the nesting the higher the penalty.
Why? Nested classes are not a problem i
Hello,
*** Short version (more technical) ***:
Pointers to classes should be stored in a CPU or GPU pointer cache to prevent
the pointer from being pushed out of the cache by other data items which might
never be accessed again.
Pointers to classes have a higher likelyhood of being used again
42 matches
Mail list logo
