Philipp Klaus Krause wrote:
> Now that I've compiled bitcc I have some questions about bitc and bitcc.
> I'm looking for an alternative to C/asm programming for embedded
> systems. I need a language that compiles to C (just plain C, no
> dependencies on any libraries, if I don't use terminal io in a program
> the output should not require printf, etc) and integrates well with
> existing C and assembler code.
> 
> Is the output of bitcc just plain C? 

The main library dependency currently is the Boehm-Demers-Weiser garbage 
collector. However, there is a --no-gc mode in BitC, which is designed 
to be used for low level software that must not perform dynamic 
allocation. This mode precludes (that is, rejects at compile time) all 
runtime allocation including construction of values of type vectors, 
reference structure/union and closures.

Currently, the linkage with gc library is not removed even with the 
--no-gc version. There is a small issue regarding the the type of main 
routine (we defined it as (vector string)). After this is resolved, we 
don't need the gc library if one only uses the subset language supported 
in the --no-gc mode.

Presently, we are also always linking with libbitc, which includes 
support for standard I/O. However, removing this linkage (ex: by adding 
a special mode) would be trivial.

> Many other compilers that compile
> to C need libraries of gcc-specific stuff. Does it use any advanced
> features of the C language like the C99 types for complex numbers or
> structures as return values or double precision floating point numbers?
> If yes, will these always be needed or only if I use certain parts of
> the bitc language?

We don't use GCC specific features, but do produce C99 code. We don't 
use complex numbers. Double precision / floating point numbers are only 
used in the program actually uses them.

However, there is one place where we currently use structures as return 
values even though the program itself may not return a `by-value' 
structure. If we have a unboxed structure/union, the constructor for 
that structure/union is implemented as a function that builds up the 
required datastructure and return it by value.

> Are there any bitc tutorials?

No. All we have now are the examples embedded in the BitC spec (and 
other documents) plus the test programs we have in the BitC tree. The 
unit tests have a lot of simple examples which exercise (individually) 
all parts of the language. The IA32 directory has an example of the 
Pentium GDT structure written in BitC.

> How efficient is the bitcc output? I don't have much RAM (1K) or ROM (32K).

We have not performed specific measurements. Before the implementation 
of closure conversion in BitC, I looked at the object code produced for 
some small programs (factorial, etc) and they looked pretty close to the 
object code output for the corresponding C code when compiled in gcc 
along with the -O2 flag. At present, we are performing a pass that 
transforms all functions to closures, which will limit the ability of 
the compiler to optimize certain calls to functions that actually don't 
need closures. However, if you use the --no-gc mode, there is no need to 
do closure conversion and the output should be -- according to my 
expectation -- comparable to the C code.

In the present commit, support for --no-gc is not complete. So, you will 
actually see closure conversion being performed even though the compiler 
will reject all functions that actually capture non-locals. This problem 
should be fixed shortly.

Apart from this issue, I think the space utilization in BitC should be 
quite efficient, since it supports precise representation control. 
However, it might not be as efficient as hand-optimized (and potentially 
unsafe) assembly code.

Swaroop.

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to