llvm dev - May 2016 - A "Cross-Platform Runtime Library API" in LLVM IR

On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at icloud.com>
wrote:
> 
> I'm not talking about a new library instead of the libc, I'm
talking about letting people create a library optimized for a specific frontend,
regardless of the target.
It sounded as if you were talking about a library that sits underneath such a
thing.  Lots of languages have their own runtime libraries (I maintain two of
them), including Go, C++, Swift, and Objective-C.  These are generally intended
to be portable across front ends, defining the low-level binary interfaces that
compilers target.

David

You guys are saying that the library which defines the runtime library is
written in C for many languages.
The problem is that such functions are in the libc and so the object files have
to be linked against the **entire** libc.
Sorry if I'm wrong but isn't it a little inefficient or hard to handle?
With "hard to handle" I mean the entry point:
if I use C's I/O operations, ain't I forced to use the C _start()
implementation that calls its initializers (such as stdin and stdout
initialization) before calling main() ?

I was thinking about maybe trying to make the languages runtimes independent
from the C runtime. Wouldn't it make runtimes faster?
> On May 23, 2016, at 1:19 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
>> On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at
icloud.com> wrote:
>> 
>> I'm not talking about a new library instead of the libc, I'm
talking about letting people create a library optimized for a specific frontend,
regardless of the target.
> 
> It sounded as if you were talking about a library that sits underneath such
a thing.  Lots of languages have their own runtime libraries (I maintain two of
them), including Go, C++, Swift, and Objective-C.  These are generally intended
to be portable across front ends, defining the low-level binary interfaces that
compilers target.
> 
> David
>

At least for Linux/Unix, there's very little you can actually achieve
without at least some of the libc linked into your own system. Unless you
actually write your own system call interface functions - which is
dependent on the processor architecture (using `int X` [or `syscall`] in
x86, perhaps `trap Y` in 68K, `swi` on ARM, etc) - values for X may vary
depending on OS too, and ABI (different registers/calling convention may
exist for the same architecture) - and of course, it will be yet different
on Windows, either way. Using standard library functions in the C library
will give a reasonable semblance of working on most platforms for which
there is a C compiler.

Sure, you can reduce the size of the application itself by a fair bit [when
statically linked - my typical Pascal test executables are in the tens of
kilobytes, because they dynamically link to libc], but I very much doubt
you'll gain much overall time from using something other than libc - but
you'll end up doing a lot of work.

Do, by all means, investigate this, and if you find some significant
savings, report back. But in general, I'd say, you probably end up doing
the same thing that libc does already. And most languages need some
start-up code, so calling `_start` at that point isn't such a terrible
thing. I use the C compiler as a linker, so I just call my language's
startup `main` and be done with it. But you'll probably find yourself
implementing something like this:
https://github.com/Leporacanthicus/lacsap/blob/master/runtime/main.c
either way, even if it's not precisely called `main`, and isn't written
in
C.

Yes, it's necessary to call `_start` or equivalen, if you want to `stdin`
and `stdout`, to initialize those - but sooner or later, you'll end up
wanting to buffer I/O a little bit beyond calling the OS read/write
operations (`write` is pretty rubbish for implementing `printf` or Pascal's
`writeln` - because you get far too many user-kernel-user transitions,
making it slow), and most likely, you don't want to call `sbrk` and `mmap`
to allocate memory directly either. So, the runtime library for language X
will have to have some runtime library that sets things up in accordance to
how it's file and memory handling.

The key point here is "how much do you gain, and how much effort is
it". If
it's a very small gain, and a large amount of effort, is there something
else that makes it meaningful to do? So far, I see no such case.

By all means, if you want to implement your own language, and write your
own runtime to go with that, LLVM will allow that. But you will need to
implement some reasonably efficient handling of file-I/O and memory
allocation for each OS you want. And a reason why you won't want to do ONE
library that allows this for many languages is that different languages
have different semantics for the DETAILS of how you do certain things
(error handling could be throwing exceptions, returning error codes,
aborting the execution - or some combination thereof based on compiler or
language pragma, etc, etc).

--
Mats

On 23 May 2016 at 12:35, Lorenzo Laneve <lore97drk at icloud.com> wrote:
> You guys are saying that the library which defines the runtime library is
> written in C for many languages.
> The problem is that such functions are in the libc and so the object files
> have to be linked against the **entire** libc.
> Sorry if I'm wrong but isn't it a little inefficient or hard to
handle?
> With "hard to handle" I mean the entry point:
> if I use C's I/O operations, ain't I forced to use the C _start()
> implementation that calls its initializers (such as stdin and stdout
> initialization) before calling main() ?
>
> I was thinking about maybe trying to make the languages runtimes
> independent from the C runtime. Wouldn't it make runtimes faster?
>
> > On May 23, 2016, at 1:19 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
> wrote:
> >
> >> On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at
icloud.com> wrote:
> >>
> >> I'm not talking about a new library instead of the libc,
I'm talking
> about letting people create a library optimized for a specific frontend,
> regardless of the target.
> >
> > It sounded as if you were talking about a library that sits underneath
> such a thing.  Lots of languages have their own runtime libraries (I
> maintain two of them), including Go, C++, Swift, and Objective-C.  These
> are generally intended to be portable across front ends, defining the
> low-level binary interfaces that compilers target.
> >
> > David
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/ed64246d/attachment.html>

On Mon, May 23, 2016 at 01:35:29PM +0200, Lorenzo Laneve via llvm-dev
wrote:
> You guys are saying that the library which defines the runtime library is
written in C for many languages.
> The problem is that such functions are in the libc and so the object files
have to be linked against the **entire** libc.
> Sorry if I'm wrong but isn't it a little inefficient or hard to
handle?
> With "hard to handle" I mean the entry point:
> if I use C's I/O operations, ain't I forced to use the C _start()
> implementation that calls its initializers (such as stdin and stdout
> initialization) before calling main() ?
And? The CRT startup often does a variety of things and if you want to
co-exist with C libraries at all, you won't be able to avoid it. Even if
you can avoid it, it adds a lot of OS and target specific knowledge to
your language runtime with little gain. Even for static linkage, a well
written stdio implementation is not that heavy. Just because glibc
requires 2MB for static linking hello-world, doesn't mean everyone else
does.
> I was thinking about maybe trying to make the languages runtimes
> independent from the C runtime. Wouldn't it make runtimes faster?
Unlikely. You might be able to reduce startup time a bit, but even that
is quite possible in the noise. On the other hand, you gain all the
advantage of dealing with different system call conventions, different
ways for managing kernel ABI compatibility etc. It's a pain when dealing
with Go already...

Joerg