Re: [Gcc4cli-devel] Libstd, many doubts

[David Y. <dav...@in...>]

First of all, thanks for the explanation.

Well, actually after reading your mail and examining all the versions of each library, I better understand why we need this "framework". Also, I realize that I was too focused towards the "gcil way" (which is probably the less interesting one).

Regarding libstd and some posix headers, you are right, we cannot just take the system ones, since there are many platform specific features. Moreover, after looking at the whole picture, I realize that we don't mess up the headers, we just provide a component that cil32 needs to properly work (in a platform independent way), and a set of libraries for runtime compatibility. 

I continue with the original way: adapted headers + Libstd.dll + the two MSCorelibWrapper.dll. I think that your mail was clarifying enough, so I think that we won't need the phone call for the moment.

Thanks,
David

----- Mail original -----
> De: "Andrea Carlo Ornstein" <and...@gm...>
> À: "David Yuste" <dav...@in...>
> Cc: gcc...@li...
> Envoyé: Mardi 8 Février 2011 15:43:00
> Objet: Re: [Gcc4cli-devel] Libstd, many doubts
> The main idea of libstd is to abstract the libc so the compiler can
> generate a binary that is independent from how it will be run.
> It is implemented in C and compiled with gcc4net.
> 
> The library is an implementation of the standard libc on top of a set
> of primitives that are defined in MSCorelibWrapper.dll
> 
> There are two different implementations of MSCorelibWrapper.dll
> the first one is implemented with calls to MSCorelib and so all your
> application is CLI, you can run it where you want with any VM
> the second one is implemented with calls to the native libc and so it
> is not portable, it does the proper conversions needed on the target
> from the standard interface exposed by libstd and the native
> implementation, you need one for each target
> 
> So your application always use libstd (that is a valid CLI binary and
> provides the libc) wich uses MSCorelibWrapper.dll (that can be
> portable or optimized for a specific target)
> 
> After that when we decided to use CLI as an intermediate
> representation we had different choices.
> to translate also the libstd from cli to native and keep the binding
> to the native target at the MSCorelibWrapper.dll level
> or to understand where the libc was starting and, if the layout of the
> implementation of libstd was compatible with the native one, replace
> the calls to libstd directly with calls to the target native
> libraries.
> For lack of time we decided for the second.
> 
> If you want to use another libc implementation, you can do it.
> But you have to port it
> on what?
> Do you target MSCorlib, so it is portable and runs on all VMs?
> MScorlib have a lot of high level abstractions but usually the
> implementations of libc start from system calls provided from the OS
> how do you match the two abstraction levels is not easy.
> 
> If you use it as an intermediate IR instead what we want to do?
> Logically I would like to use directly the headers of the target
> but this implies that I have to understand all the nuances used in the
> implementation of the headers of that target, at least
> if you look at the gnu libc you will see a lot of inline assembly,
> attributes target dependent and so on
> So we end up having to include in the compiler the interpretation of a
> lot of stuff for each target that we want to support.
> 
> I just wrote it down quickly, but it is best if we hear each other by
> phone.
> Andrea
> 
> 
> 
> On Mon, Feb 7, 2011 at 3:38 PM, David Yuste <dav...@in...>
> wrote:
> > Hi all,
> >
> > In order to support most of the SPEC2000 benchmark, we must provide
> > many
> > libstd and unix/posix headers. I'm about to commit many of them into
> > the
> > cli-be branch, but before I'd like to clarify and discuss some
> > concepts
> > (because may be we can do something better/easier)
> >
> > As far as I understood, there are several ways to execute a CIL
> > binaries
> > produced by cli-be (regarding libstd). For instance, when gcil is
> > used,
> > calls to libstd are just intercepted (while parsing) and replaced
> > with the
> > corresponding native call. When Mono or .NET is used, I think that
> > the
> > versions in MSCorelibWrapper.dll and/or (??) Libstd.dll are called.
> > However,
> > there are many things that I don't really understand:
> >
> > - What are the .c files in gcc/libstd/src/, when are they used? In
> > order to
> > build Libstd.dll? (but it is C code!)
> > - What do we expect from MSCorelibWrapper.dll and what from
> > Libstd.dll? When
> > do we use each one?
> > - How do the macros in every .h file of gcc/libstd/inluce/ work?
> >
> > Also, another issue is the following. We do special effort to don't
> > mess up
> > with gcc, thus we put everything in a separate folder, and so on...
> > but, we
> > mess up the whole libstd?? Is not there a better way to do it? Also,
> > note
> > that this issue enforces as to rewrite almost every header in order
> > to be
> > compatible with ordinary programs.
> >
> > So, in conclusion, my question is about the libstd compatibility
> > philosophy,
> > details on how does it work, and why it worths to mess up all the
> > headers.
> >
> > Thanks,
> > David
> >
> >
> >
> > ------------------------------------------------------------------------------
> > The modern datacenter depends on network connectivity to access
> > resources
> > and provide services. The best practices for maximizing a physical
> > server's
> > connectivity to a physical network are well understood - see how
> > these
> > rules translate into the virtual world?
> > http://p.sf.net/sfu/oracle-sfdevnlfb
> > _______________________________________________
> > Gcc4cli-devel mailing list
> > Gcc...@li...
> > https://lists.sourceforge.net/lists/listinfo/gcc4cli-devel
> >
> >