<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9">
</HEAD>
<BODY>
Kewl Beans! You're heading right where I need LLVM to go :) <BR>
<BR>
Details ...<BR>
<BR>
On Wed, 2003-11-12 at 07:22, John Criswell wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I> Funny you should mention that; getting a C library compiled to LLVM
code is one of the tasks on my plate. :)</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Good. If I can help, please let me know.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I> You are correct that the LLVM assembly language cannot accept native
assembly instructions or access machine specific features directly.
However, there is hope:
Long term, one of our projects is to port the Linux kernel to LLVM.
This project has the same problem that you have encountered; how to
access machine specific services.
Our current plan is to add a set of intrinsic functions that will give
us access to the hardware facilities that we need. For example, we will
probably have an intrinsic that registers a function as a system call
handler, another intrinsic that performs I/O, another intrinsic that
tells us what hardware is connected to the machine, etc, etc.</I></FONT></PRE>
</BLOCKQUOTE>
I'd vote for just adding a new keyword, syscall, that works just like a declare. For example:<BR>
<BR>
syscall int "__mmap" (void* start, long length, int prot, int flags, int fd, unsigned offset);<BR>
<BR>
This would indicate that unlike a "declare" of the same form, calls to mmap would invoke special<BR>
handling by placing arguments in registers and invoking a system trap .. details left to the backend.
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
In this way, the actual hardware can be abstracted away so that LLVM
bytecode programs don't need to know about it. All they see is a set of
intrinsic functions for the particular piece of hardware/OS upon which
they run.</I></FONT></PRE>
</BLOCKQUOTE>
A wonderful idea. Much of the code I've written is to abstract away the operating system interface so<BR>
that XPL can be ported to many platforms. You're actually going one step further and abstracting the<BR>
hardware. This is totally cool!
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
Please note that the Linux kernel project is still in its infancy and
won't be done for awhile. :)</I></FONT></PRE>
</BLOCKQUOTE>
Any ballpark ideas on when an alpha version could be available? Are we talking months or years here?
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
In the meantime, there are still things you can do. Please see below...
>
> What is the alternative? Write a library function in C and have it
> called by LLVM?
First, I should probably mention that an LLVM program has access to
just about all OS services offered to a regular native code program.
This is because undefined symbols in an LLVM program are resolved when
it is generated to native code.</I></FONT></PRE>
</BLOCKQUOTE>
Yes, I'd figured that out. Using just LLVIS you wouldn't be able to get anything to run :)
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
Specifically, if you JIT a program using lli, the JIT looks the symbol
up in its own address space. That is how LLVM programs find the system
calls and other library functions that are not compiled to LLVM bytecode.
For native code, the symbols are resolved at native code link time
(i.e. you run llc on the bytecode and then assemble it and link it).
For writing code that does special stuff (accesses machine registers,
etc), there are several alternatives:
1) As you suggested, you could write a library in C and compile it to
native code. You would then be able to link this library with LLVM code
(either by loading it into the JIT with -load or by using llc to
generate native code and linking to your library).
2) You could add an intrinsic for it. I'd only recommend this if it's
something that would be useful as a generic primitive; an intrinsic to
read performance registers would be okay; an intrinsic for creating
prime numbers would not.</I></FONT></PRE>
</BLOCKQUOTE>
Yes, keeping the set of intrinsics small and generally applicable to the abstraction will be important. <BR>
Unfortunately, however, there are several corner cases where the general abstraction won't work. Machine<BR>
specific capabilities (array processors and hardware neural nets comes to mind) would have to be accessed<BR>
directly. This is why LLVM needs an assembly pass through. No matter how good the LLVM abstraction <BR>
layer is at blending out differences in machine specific operations, there will always be corner cases like<BR>
this that just don't lend themselves to abstraction.<BR>
<BR>
I'd vote for an "asm" instruction that just passes literal text through to the back end. Let the user ensure<BR>
its for the right hardware, etc. For example:<BR>
<BR>
asm " movl 4(%esp), %eax<BR>
andl $0xffff, %eax<BR>
rorw $8, %ax<BR>
ret"<BR>
<BR>
The danger here is that the feature gets over used and subverts optimization. Still, for the things that <BR>
need it, it would be the right thing.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
>
> The reason I'm asking is that I'd like as much code as possible to be
> open to optimization by LLVM. If the core of my runtime library can't be
> expressed in LLVM then it can't be optimized by it either. Ideally,
> everything except the glue for system traps, interrupts and the like
> should be expressible in LLVIS.
>
That is where we are headed; we just have a way to go before we're there.
If you have any further questions, please feel free to ask. I realize
I'm being pretty verbose here.</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Sounds great. Please keep me posted on progress and let me know if there are things I can do<BR>
to help. This effort is in my best interest too.<BR>
<BR>
Verbosity is a good thing! Thanks for the explanation.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#301fe4"><I>
Regards,
-- John T.</I></FONT></PRE>
</BLOCKQUOTE>
<BR>
Reid.
</BODY>
</HTML>