Re: Intermediate forms (again?): worthwhile?

Steven Shaw <steshaw@gmail.com>
Mon, 24 Jan 2011 01:18:59 -0800 (PST)

          From comp.compilers

Related articles
[10 earlier articles]
Re: Intermediate forms (again?): worthwhile? cr88192@hotmail.com (BGB) (2011-01-19)
Re: Intermediate forms (again?): worthwhile? cr88192@hotmail.com (BGB) (2011-01-22)
Re: Intermediate forms (again?): worthwhile? ehog.hedge@googlemail.com (chris dollin) (2011-01-22)
Re: Intermediate forms (again?): worthwhile? nospam@myisp.net (Tony) (2011-01-22)
Re: Intermediate forms (again?): worthwhile? bc@freeuk.com (Bartc) (2011-01-23)
Re: Intermediate forms (again?): worthwhile? steshaw@gmail.com (Steven Shaw) (2011-01-24)
Re: Intermediate forms (again?): worthwhile? steshaw@gmail.com (Steven Shaw) (2011-01-24)
Re: Intermediate forms (again?): worthwhile? barry.j.kelly@gmail.com (Barry Kelly) (2011-01-24)
Re: Intermediate forms (again?): worthwhile? nospam@myisp.net (Tony) (2011-01-24)
Re: Intermediate forms (again?): worthwhile? thomas.mertes@gmx.at (tm) (2011-01-24)
Re: Intermediate forms (again?): worthwhile? eh@electrichedgehog.net (Chris Dollin) (2011-01-26)
Re: Intermediate forms (again?): worthwhile? bc@freeuk.com (Bartc) (2011-01-26)
Re: Intermediate forms (again?): worthwhile? cr88192@hotmail.com (BGB) (2011-01-26)
| List of all articles for this month |

From: Steven Shaw <steshaw@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 24 Jan 2011 01:18:59 -0800 (PST)
Organization: Compilers Central
References: 11-01-108
Keywords: translator, C
Posted-Date: 26 Jan 2011 12:15:36 EST

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?



Post a followup to this message

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