3 ms·

I will try to ignore the shallow (but horrifying) issue of identifiers including spaces. The real question to be asked here is what is wrong with the current p

I will try to ignore the shallow (but horrifying) issue of identifiers including spaces. The real question to be asked here is what is wrong with the current portable assembler (C) ? C has occupied this niche for a long time and quite successfully - I believe all current mainstream kernels are written in C (or possibly a limited subset of C++). If you want a 'portable assembler', a modern C compiler is in my opinion, a good choice: - a solid specification: detailing the behaviour of operations, what is defined, implementation, or undefined behaviour. - access to platform specific features through builtins and intrinsics - ability to use inline asm if you really want to (or need to) - easy integration with existing libraries - minimal dependencies on a runtime library (pretty much none in freestanding implementations) - most compliers give have ways to get good control of both what code is generated and structure layout. The modern C ecosystem provides (mostly good) tools for: - tracking memory leaks/invalid memory accesses (valgrind) - static analysis (clang static analyser, sparse, coverity, ...) - debuggers (gdb ...) - solid optimizing compilers (icc, gcc, llvm) - profilers (oprofile, perf, vtune, ...) Admittedly, most of these tools don't depend on the code being written in C, but I suspect any new language would take a while to get properly integrated. If you want to use a low level language, you really want to have access to these tools or equivalent. A new language trying to compete in this space would have to offer something fairly substantial to get me to switch - and a strange syntax like zinc is not going to help. From the documentation at least, zinc seems to currently be missing: an equivalent to volatile; asm; anyway to access a CAS like instruction; 64bit types; floats; a way to interface to C code; clear documentation about behaviour in corner cases (what happens if you a left shift a 32bit value by 40?). The only thing seems to bring to the table to compensate is the ability to inherit structures

haberman 16y ago
I agree with you. I just wanted to list the one complaint I do have about C: missed optimization opportunities due to lax aliasing rules. Consider the following C translation unit: void foo(const int *i); void bar(); int baz() { int i = 1; foo(&i); return i + 1; } int quux() { int i; foo(&i); i = 1; bar(); return i + 1; } You'd like to think that both baz() and quux() could compile the return statements to a constant "return 2." After all, foo() is taking a pointer to a CONST int. But alas, this is not the case, because foo() could cast away the const. So in truth, both functions are forced to reload the integer from the stack, add 1 to it, and then return that! You can't use any values you had loaded in registers (or in this case, you can't evaluate the expression at compile time). My example is contrived, but you can easily construct examples that fit the same pattern and are real. I've heard that Fortran still beats C in optimization in some cases; I would expect that the above is one major reason why. C99's "restrict" addresses some of the difference but cannot help you with the above.
fanf2 16y ago
The main problems with C are inability to control memory layout in fine detail, and lack of control over the calling sequence - you can't portably get a tail call. Have a look at the C-- work by Simon Peyton Jones and Norman Ramsey and others for more details.

haberman 16y ago

I agree with you. I just wanted to list the one complaint I do have about C: missed optimization opportunities due to lax aliasing rules. Consider the following C translation unit: void foo(const int *i); void bar(); int baz() { int i = 1; foo(&i); return i + 1; } int quux() { int i; foo(&i); i = 1; bar(); return i + 1; } You'd like to think that both baz() and quux() could compile the return statements to a constant "return 2." After all, foo() is taking a pointer to a CONST int. But alas, this is not the case, because foo() could cast away the const. So in truth, both functions are forced to reload the integer from the stack, add 1 to it, and then return that! You can't use any values you had loaded in registers (or in this case, you can't evaluate the expression at compile time). My example is contrived, but you can easily construct examples that fit the same pattern and are real. I've heard that Fortran still beats C in optimization in some cases; I would expect that the above is one major reason why. C99's "restrict" addresses some of the difference but cannot help you with the above.

fanf2 16y ago

The main problems with C are inability to control memory layout in fine detail, and lack of control over the calling sequence - you can't portably get a tail call. Have a look at the C-- work by Simon Peyton Jones and Norman Ramsey and others for more details.