Hello fpc-devel-admin,

fdadetn> Send fpc-devel mailing list submissions to fdadetn>

fdadetn> To subscribe or unsubscribe via the web, visit fdadetn> http://lists.freepascal.org/mailman/listinfo/fpc-devel fdadetn> or, via email, send a message with subject or body 'help' to fdadetn>
fdadetn> You can reach the person managing the list at fdadetn>

fdadetn> When replying, please edit your Subject line so it is more specific than fdadetn> "Re: Contents of fpc-devel digest..."

fdadetn> Today's Topics:

fdadetn> 1. A question about old style objects (Pavel V. Ozerski) fdadetn> 2. Re: A question about old style objects (Peter Vreman)

fdadetn> --__--__--

fdadetn> Message: 1
fdadetn> To:
fdadetn> Organization: Sechenov Institute of Evolutionary Physiology and fdadetn> Biochemistry, Russian Academy of Science
fdadetn> From: (Pavel V. Ozerski)
fdadetn> Date: Mon, 29 Oct 2001 11:31:08 +0300 (MSK) fdadetn> Subject: [fpc-devel]A question about old style objects fdadetn> Reply-To:

fdadetn> Hello all,
fdadetn> I found in Russian-language forum (FPC community) a question about possibility to use RTTI with fdadetn> BP-style objects. First my idea was to answer "no" but I made a smallest test:

fdadetn> {$ifdef FPC}
fdadetn> {$smartlink on}
fdadetn> {$typeinfo off}
fdadetn> {$endif}
fdadetn> type
fdadetn>  t1=object
fdadetn>   constructor Create;
fdadetn>   procedure Test;virtual;
fdadetn>  end;
fdadetn>  t2=object(t1)
fdadetn>   procedure Test;virtual;
fdadetn>  end;
fdadetn> constructor t1.Create;
fdadetn>  begin
fdadetn>  end;
fdadetn> procedure t1.Test;
fdadetn>  begin
fdadetn>   writeln('11111111111111111111111111');
fdadetn>  end;
fdadetn> procedure t2.Test;
fdadetn>  begin
fdadetn>   writeln('22222222222222222222222222');
fdadetn>  end;
fdadetn> type
fdadetn>  p2=^t2;
fdadetn> var
fdadetn>  t:^t1;
fdadetn> begin
fdadetn>  t:=new(p2,create);
fdadetn>  t^.Test;
fdadetn> end.

fdadetn> I became very surprised when I looked into created .exe file and found in it 11111111111111111111111111 string. fdadetn> BP7, Delphi 3, Delphi 6 cutted unused t1.test method out from .exe, FPC 1.1 (and also VP 2.1) kept it in .exe. fdadetn> What is the mean, to keep unused BP-objects methods in .exe although old objects are not designed for RTTI? fdadetn> Or FPC does support RTTI for these objects? Then, IMHO, it is a unnecessary feature because then old-style fdadetn> objects will be useless (but in Borland products they are useful because allow to write compact high-optimized fdadetn> applications; a good demonstration is KOL - free Key Object Library for Delphi).

fdadetn> Sincerely, Pavel

fdadetn> --__--__--

fdadetn> Message: 2
fdadetn> To:
fdadetn> From: Peter Vreman
fdadetn> Subject: Re: [fpc-devel]A question about old style objects fdadetn> Date: Mon, 29 Oct 2001 08:56:36 GMT
fdadetn> Reply-To:

> Hello all, > I found in Russian-language forum (FPC community) a question about possibility to use

fdadetn> RTTI
fdadetn> with

fdadetn> 11111111111111111111111111 string.

> BP7, Delphi 3, Delphi 6 cutted unused t1.test method out from .exe, FPC 1.1 (and also VP

fdadetn> 2.1) kept it in .exe.

> What is the mean, to keep unused BP-objects methods in .exe although old objects are not

fdadetn> designed for RTTI?

> Or FPC does support RTTI for these objects? Then, IMHO, it is a unnecessary feature

fdadetn> because then old-style

> objects will be useless (but in Borland products they are useful because allow to write

fdadetn> compact high-optimized

> applications; a good demonstration is KOL - free Key Object Library for Delphi).

fdadetn> The VMT of t2 contains a reference to the VMT of t1. And that one contains a reference to fdadetn> t1.Test.

fdadetn> I don't know an easy solution to remove this kind of unused code. And IMHO it has a very fdadetn> low priority to be solved.
And why not to add RTTI to standart objects ? (or function, to let just know the exact object type by pointer to it ?)

That will only generate more data. And the question was to reduce the amount of data.

But why do you need RTTI for objects? standard objects are available for backwards compatibility. All the new things like properties, interfaces are only for classes.

Peter

Hello all,

IMHO, there are exists some reason, to make cutting out unused old-style objects methods. An argument for it - the popularity of KOL (I hoped to port it to FPC but now that seems to be senseless, at least while unused methods are keeping in executable). I'm not sure that introducing of this feature must cause very big compiler alteration. Maybe, a possible way would be:
1) for old-style objects: not saving in VMT direct addresses of virtual methods but reserving space (pointer variables) for every virtual method;
2) at building PASCALMAIN-contained module: creating in initialization code assignments of addresses of used methods to these placeholders. If methods were not used, theirs placeholders in VMT will remain nil. This way will cause small slowing down of virtual methods calling, will also increase size of PASCALMAIN-contained module and initialization time but it can help to essentially reduce size of executables which use old object libraries. I think, 4 bytes for empty placeholder is better than linked dead code which can be much larger.

I send this idea to weigh it together.

Sincerely, Pavel.

Hello all, IMHO, there are exists some reason, to make cutting out unused old-style objects

methods.
An argument for it -

the popularity of KOL (I hoped to port it to FPC but now that seems to be senseless, at

least while unused

methods are keeping in executable). I'm not sure that introducing of this feature must

cause very big compiler

alteration. Maybe, a possible way would be: 1) for old-style objects: not saving in VMT direct addresses of virtual methods but

reserving space (pointer variables)

for every virtual method; 2) at building PASCALMAIN-contained module: creating in initialization code assignments

of
addresses of used methods

to these placeholders. If methods were not used, theirs placeholders in VMT will remain

nil. This way will cause small

slowing down of virtual methods calling, will also increase size of PASCALMAIN-contained

module and initialization time

Startup time is also very important, see the KDE project for discussions about startup time of c++ applications

but it can help to essentially reduce size of executables which use old object

libraries.
I think, 4 bytes for empty placeholder

is better than linked dead code which can be much larger. I send this idea to weigh it together.

It looks simple as you write it here, but adding support for it is not that simple. Because it is now easily know which virtual method is called. Only a call with an index value is generate and not a reference to the method itself.

And for the final result it'll not be a very big improvement. Having better shared library support working reduces size of executables a lot more. Also having an internal linker is much more needed as it'll simplify also cross platform compiling.

Hello,
I would to dispute a little.

It looks simple as you write it here, but adding support for it is not that simple. Because it is now easily know which virtual method is called. Only a call with an index value is generate and not a reference to the method itself.

Old-style objects have only static constructors, that is a way to find used methods

And for the final result it'll not be a very big improvement. Having better shared library support working reduces size of executables a lot more.

It's an illusion, that would be true only if lot of different programs (desirablely including OS ) would use these shared libraries. Otherwise size of product = size of executable + size of shared libraries designed for it.

Also having an internal linker is much more needed as it'll simplify also cross platform compiling.

May be, it would be better at current stage, to build cross-ld from gcc sources?

Sincerely, Pavel

Hello,

What is current Sibyl state? SpeedSoft home page is not updated since 1998, but I found in Internet some parts of Sibyl (sources of IDE and VCL) with 1999 and 2001 date and LGPL license. Are they valid open source or somebody added LGPL info without permission? If some Sibyl parts are valid open sources, the "marriage between Sibyl and Lazarus" could be very interesting and useful.

Pavel.

IIRC, the megido project (the first attempt to make something compatible with the VCL for FPC) convinced the
SpeedSoft people to release the Sibyl sources under the LGPL, so Sibyl should be still LGPLed.
I have the whole stuff which was released under the GPL here.

Hello,

May be, these found problems are obsolete and are lready fixed but I could report them.

FPC 1.1 (my compiler is based on 1-Nov sources):
1) does not support set of boolean, unlike Delphi and VP;
2) sizeof applied to set types demonstrates that sets in FPC are not the same as sets in Delphi and VP:

{$apptype console}
type
 t1=set of 0..1;
 t2=set of 0..15;
 t3=set of 0..31;
 t4=set of 0..63;
 t5=set of 0..127;
 t6=set of 0..255;
begin
 writeln(sizeof(t1),' ',
         sizeof(t2),' ',
         sizeof(t3),' ',
         sizeof(t4),' ',
         sizeof(t5),' ',
         sizeof(t6));
end.

Output:

Delphi 3, Delphi 6, VP2.1:
1 2 4 8 16 32

FPC 1.1:
4 4 4 32 32 32

Sincerely,
Pavel

We know about this, but it isn't fixed yet and it requires a lot of work to fix it :/
It simply has historical reasons. When I implemented the first set support in FPC
(probably 7 years ago) I was far away from thinking about making FPC TP or Delphi compatible.
So I decided to support only two set sizes: 4 and 32 bytes to make things easier.

shouldn't compiler giver werropr/warning then, eg 'Error fpc only supports 4/32 byte set sizes' or similar, when non 4 or 32 set sizes are used...That's surely better than wrong or dubious results. J

Subject: Re: [fpc-devel]Some set problems

We know about this, but it isn't fixed yet and it requires a lot of work to fix it :/
It simply has historical reasons. When I implemented the first set support in FPC
(probably 7 years ago) I was far away from thinking about making FPC TP or Delphi compatible.
So I decided to support only two set sizes: 4 and 32 bytes to make things easier.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

John wrote

shouldn't compiler giver werropr/warning then, eg 'Error fpc only supports 4/32 byte set sizes' or similar, when non 4 or 32 set sizes are used...That's surely better than wrong or dubious results. J

Only the size of the sets is different, but they are supported correctly for the rest. E.g. You get range check errors if you try to add invalid elements to the set etc.

Jonas

Only the size of the sets is different, but they are supported correctly for the rest. E.g. You get range check errors if you try to add invalid elements to the set etc.

The main problem can appear if a Delphi-compiled program will write file of set type and a FPC-compiled will read it (or vice versa).

Missing sets of boolean seems to be also important and could be easyly fixed, I think.

Pavel