Re: Intermediate forms (again?): worthwhile?

"Steven Shaw" <steshaw@gmail.com> wrote in message
news:11-01-111@comp.compilers...
> 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?


For my personal projects I Iike to keep things small, informal and
independent of other tools (especially C, but only to be
different. Although for runtimes, the C runtime library is handy). And
LLVM is on too big a scale for me.


Targetting an existing language not designed for the purpose (C) just
seems wrong. (There was something called C- or C--, but haven't heard
much about it recently.)


So I don't target a standalone language at all, except for sometimes ASM.
What I've used at various times (in some cases via an intermediate language)
are:


* Proprietory bytecode
* Native machine code created at load time
* Native code written as assembler source code
* Native code written as proprietory object code format, for use with my own
fast loader


The downside is being tied to one target platform.


>> 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?


Sometimes. But sometimes it's not possible:


external [10]int a
real b
equivalence(a[3],b)


Eg.when sharing with data already existing elsewhere (and 'a' could itself
be part of something else).


But this is just one example where you have a trivial requirement in the
front end, which can be trivially implemented in the final target, yet the
intermediate target language creates obstacles requiring you to jump through
hoops (one suggestion I had was to use memcpy() as a workaround!)


> 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.


The little experience I've had trying to build open source C projects,
suggests there are a lot of things likely to go wrong when you have
dependency on a third-party set of tools.


And if you want to create a language with a streamlined development cycle,
then this C-compiler/linker stuff makes that difficult.


>> 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.


C99 is 550 pages, C201x is 700 pages.


> What do you recommend as a target?


I was just pointing out a few problems I'd found. If someone is very
familiar with C, then certainly have a go at that as a first attempt. It
will either be satisfactory, or they will learn the shortcomings for their
project.


For professional work then LLVM looks pretty good (when you read the blurb).
But it's quite complicated (there are several dozen *sets* of documentation
and I've no idea even now whether it would fit in to the way I do things)


--
Bartc

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