C Backend and Runtime Improvements

There are many areas where we can improve the C backend to produce better code.

Function Application

Currently, using apply() results in some code that builds some buffers and has a dedicated apply_buffer on the TEB. This doesn't seem optimal.

• In the case where we know the number of arguments, can we make a more direct invocation of the right thing?
• Can we use a buffer on the stack instead of the apply_buffer on the TEB?
• Can we use memcpy instead of iterating over the items?

It is worth noting that the HARP backend generates fairly different code for this.

MV_SPILL

MV_SPILL spills to the heap but could spill to the stack. This would eliminate some GC load as well.

Int / Long Mixed

The C run-time uses int and long interchangeably in a number of areas.

• Things like vector_size, vector_ref and vector_ref_setter should be using size_t. This will bring a number of additional changes to remove all associated warnings.

Signal Handling

The C run-time doesn't do any signal handling like the HARP run-time does. This prevents code using the C back-end from correctly handling division by zero and other errors.

It may be that this should be fixed at the same time as merging the run-times or it could be done in advance of that.

Warning and Static Analysis with Clang

With a current version of Clang (currently 3.3 or XCode 5), try enabling -Weverything and the static analysis tools and look at what concerns are raised by Clang.

Thread Safety

We still use the non-thread-safe versions of some functions, like localtime. In the case of localtime, some refactoring of the code that calls it will be required to be able to use localtime_r.

primitive_sleep()

primitive_sleep() is implemented in terms of sleep() rather than nanosleep().

Old Style Code in Thread Primitives

The threading code is using ZINT, Z, and direct bit shifts (>> 2) rather than the same thing as the rest of the runtime code.