The new Delphi 2010 RTTI

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In our previous episode, [hidden email] said:
> The main problem is the Windows target where a library is more like a
> self-contained exe. On Linux (and probably Mac OS), libraries already
> work as packages are intended to work.

Could you explain this?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In reply to this post by Alexander Shishkin
In our previous episode, [hidden email] said:
> But I want packages to be binary portable between OS (on target
> processor architecture)

That's effectively not possible with all OSes providing such emulation ABI.

Esperanto for OSes so to speak.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In reply to this post by Sven Barth-2
In our previous episode, Sven Barth said:
>
> The main point with packages is that a package is a libary that can be
> loaded at runtime with some compiler magic.

IMHO that is only secondary.

The primary point is that a set of units (+mainprogram) can be divided over
multiple binaries transparently.  (without changes to the code)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In reply to this post by Matt Emson-2
In our previous episode, Matt Emson said:
> > Like I said, your proposal requires that we emulate all OSes on all
> > other OSes.
>
> Or create a VM layer that levels the OS level differences - but again,
> why do this? Creating such a VM is probably a magnitude of complexity
> over just using the tools already available and requiring a
> recompilation to target each platform.

And that is still assuming you don't need priviliged instructions or calls
to do so.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by Marco van de Voort
10.01.2011 15:31, Marco van de Voort пишет:

> In our previous episode, [hidden email] said:
>> But I want packages to be binary portable between OS (on target
>> processor architecture)
> That's effectively not possible with all OSes providing such emulation ABI.
>
> Esperanto for OSes so to speak.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
Does "inefficiently" meansperformance decreaseis this case? Is it
significant?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In our previous episode, [hidden email] said:
> >> But I want packages to be binary portable between OS (on target
> >> processor architecture)

> > That's effectively not possible with all OSes providing such emulation
> > ABI.
> >
> > Esperanto for OSes so to speak.
> >
> Does "inefficiently" meansperformance decreaseis this case? Is it
> significant?

(1) I don't know where I use the word "inefficiently".

(2) to answer the question anyway, the efficiency depends on the difference
between the target platforms.  Wine (windows on FreeBSD/Linux) is gigantic
and noticably slower, but Linux binaries on FreeBSD are next to native.
(the whole emulation is 60k and can load Linux dynlinker, libraries etc)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

michael.vancanneyt
In reply to this post by Marco van de Voort


On Mon, 10 Jan 2011, Marco van de Voort wrote:

> In our previous episode, [hidden email] said:
>> The main problem is the Windows target where a library is more like a
>> self-contained exe. On Linux (and probably Mac OS), libraries already
>> work as packages are intended to work.
>
> Could you explain this?

A Delphi DLL on windows is roughly equivalent to a exe.
A fully contained binary, no dependencies.

We currently 'emulate' this on linux, in that we stuff the whole rtl and
whatnot in the library if one is created.

However, normally, on linux, libraries are a means of spreading code over
several libraries, i.e. if you create a library, you don't put libc in it,
you link to libc. This concept is closer to packages.


Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Tomas Hajny-2
In reply to this post by Alexander Shishkin
On Mon, January 10, 2011 13:46, [hidden email] wrote:

> 10.01.2011 15:31, Marco van de Voort пи�о�:
>> In our previous episode, [hidden email] said:
>>> But I want packages to be binary portable between OS (on target
>>> processor architecture)
>> That's effectively not possible with all OSes providing such emulation
>> ABI.
>>
>> Esperanto for OSes so to speak.
>>
> Does "inefficiently" meansperformance decreaseis this case? Is it
> significant?

If you refer to the word "effectively" stated by Marco, it probably meant
"in effect", not "efficiently" (although such a solution would not be
efficient either as mentioned by Marco's response). As an example, your
proposal would imply that no external calls whatsoever would be possible
(including calls to external libraries due to them using different calling
conventions, etc.).

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Marco van de Voort
In reply to this post by michael.vancanneyt
In our previous episode, [hidden email] said:
> >> work as packages are intended to work.
> >
> > Could you explain this?
>
> A Delphi DLL on windows is roughly equivalent to a exe.
> A fully contained binary, no dependencies.

DLL's can perfectly fine depend on other binaries.

I assume you mean linker namespaces here.
 
> We currently 'emulate' this on linux, in that we stuff the whole rtl and
> whatnot in the library if one is created.

You can also emulate it the other way around by having Windows DLLs export
all symbols.

> However, normally, on linux, libraries are a means of spreading code over
> several libraries, i.e. if you create a library, you don't put libc in it,
> you link to libc. This concept is closer to packages.

Systems with linker namespaces allow you to avoid painful problems with
duplicate symbols in complex linking situations.  These don't happen as
quickly in Linux because everything is centrally organized from the
distribution (at the price of fragmentation, versioning and the missing of a
long time stable binary abi)

But IMHO neither has anything to do with packages.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
In reply to this post by Tomas Hajny-2

> As an example, your
> proposal would imply that no external calls whatsoever would be possible
> (including calls to external libraries due to them using different calling
> conventions, etc.).
>
> Tomas
>
By the way despite the fact that static linking to external libraries
will be impossible, but dynamic linking could be implemented. Anyway I
understand that platform independence of code imposes certain
restrictions and that restrictions impact on application design. F.e.
interface to external platform dependent systems should be isolated in
separate package (as I wrote about LCL and its widget sets). But I think
it makes design better.

Alex

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Jonas Maebe-2

On 10 Jan 2011, at 14:46, Alex Shishkin wrote:

> By the way despite the fact that static linking to external  
> libraries will be impossible, but dynamic linking could be  
> implemented. Anyway I understand that platform independence of code  
> imposes certain restrictions and that restrictions impact on  
> application design. F.e. interface to external platform dependent  
> systems should be isolated in separate package (as I wrote about LCL  
> and its widget sets). But I think it makes design better.

What you are proposing is something similar to Google Native Client (http://code.google.com/p/nativeclient/ 
), except that they also added code verification because it's intended  
for running native applications downloaded from websites.

That is not directly related to packages, but rather to a completely  
new run time environment with its own ABI, object format etc. The  
result of having such an environment is indeed that you can have  
compiled binary code that is portable across different operating  
systems, but that's outside the scope of adding packages support to FPC.

You first have to define such a platform (or you can take the Google  
Native Code platform), then add RTL and compiler support to FPC for  
that platform, and subsequently any program or package compiled for  
that platform by FPC will run on it. Reinventing such a platform and  
embedding it in FPC and its run time library falls outside the scope  
of the FPC project.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Alexander Shishkin
10.01.2011 17:40, Jonas Maebe пишет:

>
> On 10 Jan 2011, at 14:46, Alex Shishkin wrote:
>
>> By the way despite the fact that static linking to external libraries
>> will be impossible, but dynamic linking could be implemented. Anyway
>> I understand that platform independence of code imposes certain
>> restrictions and that restrictions impact on application design. F.e.
>> interface to external platform dependent systems should be isolated
>> in separate package (as I wrote about LCL and its widget sets). But I
>> think it makes design better.
>
> What you are proposing is something similar to Google Native Client
> (http://code.google.com/p/nativeclient/), except that they also added
> code verification because it's intended for running native
> applications downloaded from websites.
Interesting link. Thanks.
>
> That is not directly related to packages, but rather to a completely
> new run time environment with its own ABI, object format etc.
object format is the main question as for now.
> The result of having such an environment is indeed that you can have
> compiled binary code that is portable across different operating
> systems, but that's outside the scope of adding packages support to FPC.
OK
>
> You first have to define such a platform (or you can take the Google
> Native Code platform), then add RTL and compiler support to FPC for
> that platform, and subsequently any program or package compiled for
> that platform by FPC will run on it. Reinventing such a platform and
> embedding it in FPC and its run time library falls outside the scope
> of the FPC project.
>
Yes, my implementation of packages planed to be just a platform from the
compiler side. So then "native" support of packages will be added in FPC.
>
> Jonas
> _______________________________________________
> fpc-pascal maillist - [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: The new Delphi 2010 RTTI

Dimitri Smits-2
In reply to this post by michael.vancanneyt

----- "michael vancanneyt" <[hidden email]> schreef:

> > My solution, in short,  is that packages should have OS independent
> interface
> > to RTL built into executable visible to packages as RTL built as c
> package
> > (with is a bridge to real RTL).
>
> I understood that. Assuming you can make this interface (which I
> don't
> believe), your solution is still not realistic:
>
> And how will you make a package that uses a os-specific function OS
> independent ?
> (for instance, a package with a control that uses a WinAPI call.)
>
> So a package with the LCL is by definition impossible.
>
> Like I said, your proposal requires that we emulate all OSes on all
> other OSes.

I think he means a hybrid of the old 'overlay' loadable code.

and I also think he means something like:
- if you want to have a "package" for a 386 cpu, then you only have to compile it once
- you can "link" in your code regardless of os, as long as it is a 386 cpu with the same code

ofcourse I cannot agree more on the 'use what the os gives you'. ???.dll/lib???.so

what I don't understand is the remark on "windows dll is a pe executable and linux .so's are how packages are supposed to be". Anybody can clarify that statement?

kind regards,
Dimitri Smits
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123