Shuo Chen wrote:
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.