Because if you have access to assembly, you can implement the whatever higher level language or semantics you want.
Whereas if you only have a higher level language, you have to work with/around the abstractions baked into it.
For realtime applications it's better to at least have access to a low-level, less overhead API.
For example, in assembly we can create a higher level language with an absolutely air-tight, precisely tracing garbage collector that is free of issues like false retention.
We cannot do that in C. That's because there are areas of the program state that are "off limits", and the compiler generates "GC ignorant" code.
In C, if we have a pointer p which is the last reference to some object, and is not used any more, and add the line "p = NULL", hoping to drop a reference so the object can be reclaimed, there is no guarantee that the compiler actually generates the code which does the assignment. Since the variable has no next use, and the compiler doesn't know anything about garbage collection, the assignment looks like wasteful, dead code that should be optimized away. Even if the scope finishes executing, the compiler can leave behind a memory location which still references the object.
Here is something else, not related to GC. In assembly language, we can make ourselves a calling convention for variadic functions which know how many arguments they have. As we build up the higher level language, it will have nicely featured variadic functions.
In C, we are stuck with <stdarg.h> which doesn't have a mechanism for the callee to know where the arguments end. The language has no flexibility to add this --- without resorting to approaches which will basically involve assembly language.
You can do it portably if you just don't store objects on the C stack, and you can do it non-portably if you do so.
If so, you will be the first; I look forward to the "Show HN:" when it's done.
> You can do it portably if you just don't store objects on the C stack,
Sure, for example, you can do it portably in C if you write a complete emulator for an 80386, and then use that to run an assembly language program. That program isn't a utility for your C code; it's not extending the host C with a garbage collector or whatever else.
If you do not store object references on the stack, your use of C is severely crippled to the point that it's not really C any more. For one thing, C function arguments are on the stack (or, more abstractly, "automatic storage"), so say goodbye to conventional use of C argument passing: the backbone of most normal C programming.
That garbage collector isn't for C. C has automatic storage, and a proper garbage collector has to traverse it.
> and you can do it non-portably if you do so.
Sure, if non-portably means going as far as forking a specific C compiler with your custom hacks, and requiring that C compiler, or else living with the imprecision and taking a whack-a-mole approach to plugging the issues as they arise.
http://en.wikipedia.org/wiki/CHICKEN_%28Scheme_implementatio...
[edit] And here is a toy scheme interpreter that uses precise garbage collection to show off the Ravenbrook MPS
http://www.ravenbrook.com/project/mps/master/manual/html/gui...
The fact that Apple totally controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products, while Android must have an SDK which accommodates an unknown range of hardware for hundreds of products, means iOS will have an inherent advantage.
The fact that Apple totally controls both sides of the symbiotic audio hardware & SDK running on a tiny set of products