[llvm-dev] A "Cross-Platform Runtime Library API" in LLVM IR

[mats petersson via llvm-dev]

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>