Re: Intermediate forms (again?): worthwhile?

On Monday, January 24, 2011 6:09:44 AM UTC+10, Bartc wrote:
> I've attempted targetting C a few times and always gave up.


What did you end up using? What is better than C? Have you tried LLVM?


> You say C's type system is close to the hardware, but just try and
declare a > type of exactly 32-bits! It might be int or long int. On
some C's it might > be int32_t, or is it int_least32_t, or
int_fast32_t?


Mostly you can get around these problems with a portability header
file. i.e. a few preprocessor macros.


> int a
> real b
> equivalence(a,b)
>
> Here, a (32 bits) and b (64 bits) occupy the same location in
> memory. How to achieve this in C? Up to recently I might do
> something like:


Could you use a union here?


> Or, you might want to use a calling convention unknown to C. Or
> unusual ways of linking modules.


True, some C compilers might support other calling conventions but if
you're designing your own calling convention, I reckon you might be
better off generating asm/machine-code. Perhaps a better option might
be to add support for your new calling convention to your favourite C
compiler or LLVM infrastructure though.


> Just the use of identifiers is a big enough headache: C has its own
> set, yours may use some unusual ways of creating identifiers: not
> case sensitive, embedded spaces, namespaces, whatever. These
> fortunately can be got around, but it's all a lot of extra work.


It's not a lot of extra work but you could end up running into trouble
with limits of the lengths of identifiers in your favourite C
compiler.


> And then you find it will only work on a specific compiler with
> particular options, creating a dependency. So much for
> portability... And performance now depends on factors not directly
> under your control.


You could support multiple C compilers or simply generate the .c files
and leave it up to the build scripts to invoke the C compiler...


Another pragmatic option might be to use a widely available C compiler
as standard (or by default). For example gcc or tinycc or even the new
clang.


> Then if you want to debug the result, it will be in terms of the
> alien C code which the user of your language wasn't even aware of,
> complete with scrambled identifiers!


Yes, that's a nasty problem. I think some compilers have directives
which may help.


Anyone know if there's any workable solution to debugging?


> I'm not saying it's impossible to target C, but it can be more
> trouble than it's worth, with 700 pages of the C Standard to
> consider between your language, and the hardware you want to target.


Wow, I didn't know that the C standard has gotten so large.


What do you recommend as a target?

Return to the comp.compilers page.
Search the comp.compilers archives again.