What's the 'c' target? That's C code emitted by Clue. That is, we're compiling C into C. Clue's output code uses double precision floats for all numbers, but even then it's impressively fast.
To me that sounds like they're changing the program semantics. Switching to different types of floats will change your program.
I've just tried a simple case in which a program prints the output of an integer division and the output of an integer addition which overflows in 32-bit integers.
(Clue C version)
7/3 is 2, remainder is 1
2147483648 + 2147483649 is 1
The sum 1 is greater than 2147483648
(pure GCC version)
7/3 is 2, remainder is 1
2147483648 + 2147483649 is 1
The sum 1 is less or equal to 2147483648
(of program)
#include <stdio.h>
void show_division(int x, int y);
void show_division(int x, int y) {
printf("%d/%d is %d, remainder is %d\n", x, y, x/y, x%y);
}
void show_add(unsigned int x, unsigned int y);
void show_add(unsigned int x, unsigned int y) {
unsigned int z = x + y;
printf("%u + %u is %u\n", x, y, z);
if( z > x ) {
printf("The sum %u is greater than %u\n", z, x);
}
else {
printf("The sum %u is less or equal to %u\n", z, x);
}
}
int main(int argc, char* argv[]) {
show_division(7, 3);
show_add(0x80000000u, 0x80000001u);
return 0;
}
The division rounds in the expected way expected because the intermediate result is cast to integer; the addition overflows only internally in printf.
However, if you expect any particular overflow behaviour of your C integers, chances are you're not following ISO C to the letter. ISO C doesn't even guarantee two's complement representation of integers.
[edit: layout]
[edit again: layout, wishing there was a preview]
I don't really get it, is it
1) C language that gets translated into other languages ?
2) A C compiler optimized for the high level languages mentioned ?
3) Something else ?
It compiles C programs to perl or to Lua or to Java or to Lisp.
The author seems to hope that improvements in JIT technology will finally make the JIT-compiled translated programs faster than the original C program. That sounds optimistic to me, but I see two areas where this may be of use:
1. Portable execution of C code in a sand box on a web client -- just like Google Native Client, the provider of a program needs to change its build process, but the security of the VM is easier to check.
2. Checking that what you've written is ANSI/ISO C and not just, say, C for gcc on little-endian 32-bit x86 machines.
You are right on with most of what ou said. However, from the project description page, the author states the purpose as more of a "because we can! its a cool hack!" and talks about even wanting to target shell script eventually. It is just a fun hack!
In terms of actual practical value, it may be useful to allow the use of code written for one system to run on another, much more restricted system. For example, using clue you could use off-the-shelf encryption systems like gpg to work inside a web browser.
Wouldn't it be smarter to target jvm/parrot/clr directly instead of languages on top of them? Afaik it should still get full JIT optimization and portability, which should be major points.
The problem is that the reverse is actually really f'ing hard. Since the language is dynamic, you have to compile a million paths for all the different things variables can be. Thats what JIT is for.
