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

So, the backend should implement "__alloc" that does the same as
"malloc" -
or something subtly different from "malloc" - and on a Windows
machine, how
is it different from "HeapAlloc"? And "__write" that is same
as UNIX
"write", but different from "WriteFile" in Windows? And HOW
do you expect
the backend to implement these? By calling
"malloc"/"HeapAlloc",
"write"/"WriteFile"?

This is what the C library is for, it provides a set of independent
functions that are reasonably well defined and reasonably portable between
archiectures. If you are compiling something different than C, you'll need
to implement something similar [and perhaps, like I did, interface to the C
runtime library even in a non-C language with thin wrapper functions].


Sorry if I misunderstood your idea, as David says, maybe you need to
explain a bit more...

--
Mats

On 23 May 2016 at 09:11, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 22 May 2016, at 20:32, Lorenzo Laneve via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I know, that's the problem.
> > We can assume all of the system calls as runtime functions: such as
I/O,
> allocations etc. and create a set of function implemented for all the
> architectures.
> > For example, let's think about the mem allocation again: we can
provide
> a primitive function with the same name for all archs (e.g. __alloc() ) and
> then people can include this function __alloc() in their libraries,
> inlining it or even renaming it just to fit the frontend needs. And this
> can be useful: every backend should implement this set of functions (
> __alloc(), __free(), __write()… just for example) so the frontends can
> build a library with these functions as they want.
> > I don't know if you get me.
>
> I think you will need to explain a bit more.  We already have such a
> function, it’s called malloc() and a few LLVM passes assume specific
> behaviour about it.  What problem are you trying to solve?
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/dbaac78f/attachment.html>

I know but maybe malloc() is a bit higher level than a hypothetical __alloc(),
which may be lower-level and then faster.

And malloc() is contained in the libc as Matthias said and so maybe a program
using malloc() even for a non-C language linking against the crt is needed.

I'm just assuming that the functions we use in C such as malloc() are quite
high-level interfaces and that there might be something faster.

For example, does Swift use malloc() to allocate its objects?
> On May 23, 2016, at 10:18 AM, mats petersson <mats at
planetcatfish.com> wrote:
> 
> So, the backend should implement "__alloc" that does the same as
"malloc" - or something subtly different from "malloc" - and
on a Windows machine, how is it different from "HeapAlloc"? And
"__write" that is same as UNIX "write", but different from
"WriteFile" in Windows? And HOW do you expect the backend to implement
these? By calling "malloc"/"HeapAlloc",
"write"/"WriteFile"?
> 
> This is what the C library is for, it provides a set of independent
functions that are reasonably well defined and reasonably portable between
archiectures. If you are compiling something different than C, you'll need
to implement something similar [and perhaps, like I did, interface to the C
runtime library even in a non-C language with thin wrapper functions].
> 
> 
> Sorry if I misunderstood your idea, as David says, maybe you need to
explain a bit more...
> 
> --
> Mats
> 
>> On 23 May 2016 at 09:11, David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> On 22 May 2016, at 20:32, Lorenzo Laneve via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> >
>> > I know, that's the problem.
>> > We can assume all of the system calls as runtime functions: such
as I/O, allocations etc. and create a set of function implemented for all the
architectures.
>> > For example, let's think about the mem allocation again: we
can provide a primitive function with the same name for all archs (e.g.
__alloc() ) and then people can include this function __alloc() in their
libraries, inlining it or even renaming it just to fit the frontend needs. And
this can be useful: every backend should implement this set of functions (
__alloc(), __free(), __write()… just for example) so the frontends can build a
library with these functions as they want.
>> > I don't know if you get me.
>> 
>> I think you will need to explain a bit more.  We already have such a
function, it’s called malloc() and a few LLVM passes assume specific behaviour
about it.  What problem are you trying to solve?
>> 
>> David
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160523/2a7729e1/attachment.html>

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com>
wrote:
> 
> I know but maybe malloc() is a bit higher level than a hypothetical
__alloc(), which may be lower-level and then faster.
How?
> And malloc() is contained in the libc as Matthias said and so maybe a
program using malloc() even for a non-C language linking against the crt is
needed.
On many *NIX platforms, libc or some equivalent is the canonical interface to
the system.
> I'm just assuming that the functions we use in C such as malloc() are
quite high-level interfaces and that there might be something faster.
> 
> For example, does Swift use malloc() to allocate its objects?
A number of high-level language don’t use malloc, but not because it is too
high-level; quite the reverse.  You can have a more efficient malloc
implementation if you know something about allocation patterns.  For example, in
a class-based OO language you’re likely to have a small number of class sizes
and having a separate slab allocator for each of these can be faster.  If you
need garbage collection, then you’ll want to associate more metadata with
allocations.

malloc() is about as low-level an interface to memory management as is possible
while maintaining some abstraction: you give it a size (no type, for example)
and it gives you a pointer to some uninitialised memory.  The only lower-level
interfaces would be related to page table management (mmap and friends on *NIX,
more complex APIs on Mach and entirely delegated page table manipulation on
something like Xen or DUNE).

Again, what problem are you trying to solve?  What is your use case for such a
library?

David