Prof. Adve, The idea is to develop a memory model where each byte is extended with 3 extra bits. Programs are running on this memory model. Load/store instructions, including those in LibC functions, needs to deal with the extra bits in a certain manner. Basically, my questions are: (1) Is it feasible to implement the memory model where each byte is extended with 3 extra bit? (2) Is there a LLVM version of LibC (in its VM code format) currently? (3) Is LLVM able to compile HTTP servers, FTP servers and SSH servers to VM code so that every single VM instruction (include LibC code) is executed by the VM interpretor? thank you very much -Shuo On Wed, 17 Nov 2004, Vikram S. Adve wrote:> Shuo, > > >> I have a few questions about LLVM: > >> (1) The LLVM tutorial says LLVM can be used in architecture research. > >> If I want to run my program on an instruction set defined by myself, > >> is LLVM a right tool to do that? > > What kind of instruction set do you have in mind? The closer it is to > one we already target, the easier this is, but it is quite possible to > write a back-end for a relatively new one. > > > >> In this aspect, is LLVM similar to SimpleScalar simulator? > > > > You can use the interpreter as a simulator for a very abstract machine > (and extend it with any performance metrics you want). How do you > want to use it? > > --Vikram > http://www.cs.uiuc.edu/~vadve > http://llvm.cs.uiuc.edu/ > >-- ------------------------------------------------ Shuo Chen (email: shuochen at uiuc.edu) Phone: (217)333-6861 (w) (217)367-6144 (h) ------------------------------------------------
Shuo Chen wrote:>Prof. Adve, > >The idea is to develop a memory model where each byte is extended with >3 extra bits. Programs are running on this memory model. >Load/store instructions, including those in LibC functions, >needs to deal with the extra bits in a certain manner. Basically, my >questions are: >(1) Is it feasible to implement the memory model where each byte is >extended with 3 extra bit? > >I imagine that you could do this by modifying the interpretor or the JIT/code generators. Can you give a more complete description of what the memory model does (or what you have to do with these three bits)? Depending on what you're doing, you might just be able to get away with writing an LLVM transformation pass.>(2) Is there a LLVM version of LibC (in its VM code format) currently? > >Currently, no. We do not have a complete libc implementation compiled into LLVM bytecode, although someone might be working on that. In theory, the only difficult part about getting a C library to work is the interface to system calls. In a traditional libc, assembly code is used to provide that functionality and is part of the C library source code. Since LLVM cannot use assembly code, there are two options: o Add an LLVM syscall intrinsic o Write a small asm library that wraps the system calls I believe the latter would be your best option. It would be fairly easy to write and could be loaded by the JIT or linked into native code generated from the LLVM bytecode. In essence, everything above the system calls (i.e. fread, printf, etc) would be compiled into LLVM bytecode, but system calls (i.e. read/write/fork) would be native code that would be linked in. For your project, that should not be a problem. In practice, getting libc compiled with LLVM is painful because C libraries tend to have terrible build environments. For example, glibc (used on Linux) assumes that you're compiling for ELF or a.out format and uses every GCC feature that could possibly exist. Other C libraries have had strange configuration systems, or make assumptions about the operating system, etc. You can get this to work; it may just be time consuming.>(3) Is LLVM able to compile HTTP servers, FTP servers and SSH servers to >VM code so that every single VM instruction (include LibC code) is >executed by the VM interpretor? > >Well, we've compiled httpd (Apache), ftpd, telnetd, fingerd, the GNU NIS daemon, and maybe more. We haven't compiled sshd yet, but it would probably work (assuming that you can easily disable the inline asm it will use for quick compression/encryption). In theory, these should work in the interpreter, but the interpreter doesn't get as much attention as the JIT or native code generators. -- John T.>thank you very much >-Shuo > >On Wed, 17 Nov 2004, Vikram S. Adve wrote: > > > >>Shuo, >> >> >> >>>>I have a few questions about LLVM: >>>>(1) The LLVM tutorial says LLVM can be used in architecture research. >>>>If I want to run my program on an instruction set defined by myself, >>>>is LLVM a right tool to do that? >>>> >>>> >>What kind of instruction set do you have in mind? The closer it is to >>one we already target, the easier this is, but it is quite possible to >>write a back-end for a relatively new one. >> >> >> >> >>>>In this aspect, is LLVM similar to SimpleScalar simulator? >>>> >>>> >>You can use the interpreter as a simulator for a very abstract machine >>(and extend it with any performance metrics you want). How do you >>want to use it? >> >>--Vikram >>http://www.cs.uiuc.edu/~vadve >>http://llvm.cs.uiuc.edu/ >> >> >> >> > > >
On Wed, 2004-11-17 at 19:41, John T. Criswell wrote:> In theory, the only difficult part about getting a C library to work is > the interface to system calls. In a traditional libc, assembly code is > used to provide that functionality and is part of the C library source > code. Since LLVM cannot use assembly code, there are two options: > > o Add an LLVM syscall intrinsic > o Write a small asm library that wraps the system callsOr both. Writing the syscall intrinsic is easy, especially if it simply links into a native asm library to do the actuall syscall. Not that it is hard to do the codegen for the intrinsic (well, x86 linux is tricky due to the change in calling conventions at 6 args syscalls). Somewhere I have code that kind of works for x86.> In practice, getting libc compiled with LLVM is painful because C > libraries tend to have terrible build environments. For example, glibc > (used on Linux) assumes that you're compiling for ELF or a.out format > and uses every GCC feature that could possibly exist. Other C libraries > have had strange configuration systems, or make assumptions about the > operating system, etc.Also, at least with glibc, it makes uses of several C99 style variable length array at the end of stucts being statically initialized syntax that isn't supported by the current cfrontend. I've tried some other c libraries, and they were smaller than glibc, but they relied much more on assembly tricks. So the summary from last time I tried this, before I gave up for a while, is that glibc uses some C99 that isn't supported, is big and takes a while to figure out how best to convince it not to think it is compiling with gcc and asm, and other c libraries are probably even harder. Andrew Lenharth http://www.lenharth.org/~andrewl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041117/b0a6224a/attachment.sig>