On Saturday, 14 November 2015 at 08:28:08 UTC, Walter Bright
wrote:
If your new language doesn't have the C preprocessor in it,
then you must set it aside. If it does have a C preprocessor in
it, then it really isn't a new language at all, it's just a C
permutation.
But you can do code gen with standard macro invocations present,
without the compiler having the actual macro definitions (just a
representation of the semantics for the standard headers).
That's all very fine until the that C compiler evaluates
expressions in a different way than the one you debugged it
with, and your language fails on your customer's machine with
your customer's C compiler, and fails in weird ways.
IIRC C99 defines sequencing points. Granted Microsoft does not
support C99, but I'd say C99 is the standard to aim for these
days.
BTW, although C compilers exist for all kinds of weird
machines, the weirder the machine is, the worse (i.e. more
limited and buggier) the C compiler is for it (as a general
rule).
Sure enough, there are weird C compilers for DSP chips that have
32 bit integers with 24 bit ALU operations over it.
But changing the backend to emit different C for weird targets is
less work than changing a full backend...
Good luck porting your language to a C compiler that has 10 bit
bytes in it, or one with 32 bit bytes. Yes, those compilers
exist. Yes, those are C standard conforming variations. Nope,
none of your "portable" C code will work on it.
Modern C has headers with exact bit representations though.
It always is once your project exceeds trivial size. Remember,
my experience is a factor of 4x slower. And you cannot fix it.
Is the fastest non-optimizing C compiler is 4x slower than D?
Compiling to C is actually a very nice thing to have, it keeps
languages alive and limits lockin. Thanks to that we have access
to classic languages like Simula or interesting niche languages
like Mercury on a wide range of platforms. And you can make it
work (with a little effort) even if the compiler is old.
http://folk.uio.no/simula67/cim.shtml
http://www.mercurylang.org/backends.html
I could probably make these languages run as asm.js. Having a C
generating backend is an enabler.
