Looking for programming languages that compile to C

Jan 11, 2010 48 Replies

I asked this question here about one and a half years ago. I'm posting again since I'm curious about the current situation.



I want to look at alternatives to C for Z80 programming using languages that compile to C. There are the following requirements:


- Compiles to C



- Free compiler



- Low memory usage (I have only 1KB of RAM, 32KB of ROM)



Has anyone come across such a language?



The last requirement seems to be a rather hard one. Many languages that compile to C include relatively large overhead or do dynamic allocation of memory, etc. So far bitc

formatting link
seems to be the closest match, but it's abandoned.



Philipp


As you say, the last one is going to be the big problem. There are a number of languages that "compile" to C but it is typically done for smaller (in terms of users and developers) languages, which are mostly much higher level. For example, Mercury is a functional programming language which generates C code for execution, rather than having its own compiler. But it is not going to generate small C suitable for an

8-bit microcontroller. The same thing applies to, for example, the various Python-subset to C compilers around.

Generally speaking, the alternatives to C on devices of this size are C++, assembly, Pascal (there are free Pascal to C compilers available which might suit you), Ada, and Forth. For some microcontrollers there are also Basics of varying quality.

Any compiler that compiled to C was created to help people convert to C so they can get a modern supported language.

That transition was do in the 1980s.

I doubt that anyone would be doing this conversion as an active project, why would they.

As you have noticed, not much out there.

And, why would you want to write in any dead language, then convert it to C ?

Very strange.

don

At the risk of starting a flame war -- what's the matter with C?

Granted, it and younger brother C++ have numerous drawbacks, but it's like Democracy -- a terrible system, but the best we have none the less.

www.wescottdesign.com

Thats not true, C makes a good generic low-level portable universal target to compile to, much like ANTLR or LLVM or any of the other independant platform target platforms. There have been many historical comments that C is mainly a higher level version of assembly on the original platforms it was developed on (especially ancient historical versions).

You'd probably easily find a few dozen modern languages that compile to C as output.

There are many out there that compile to C. The main issue is none of them are exactly lightweight memory users, suitable for embedded systems programming which is what he is looking for.

Most likely because he has a C compiler for his target platform, and the likelyhood of finding a higher level language that compiles to C is much greater than finding a higher level language that he likes that compiles down to Z80 assembly.

An argument could certainly be made that, if you need something higher level than C in order to clearly express the problem you're working on, a Z80 might not be the tool of choice.

Rob Gaddi, Highland Technology Email address is currently out of order

There you have mentioned one possibility - LLVM has a backend generating reasonable C, and has various front-ends. Again, most of these will be too big for the Z80 - just because you /can/ use LLVM to generate C code from Python, Ruby, etc., does not mean the results will fit on the device!

Please, no offense, but do you have any links ??

I did use a Fortran to C compiler when I was in school in the early 80s.

don

Philipp Klaus Krause wrote: > I asked this question here about one and a half years > ago. I'm posting again since I'm curious about the > current situation. >

I would strongly disagree with such an argument. A 32 KB program can be quite complex, even if only 1 KB of RAM is used, so this Z80 is certainly large enough for a complex application. If the target is constrained, the programmer needs all the help he or she can get, and a high-level language can be a much more powerful "tool for thought" than C. Of course, some "high level" languages need lots of RAM, but others do not; it depends on what one means with "high level", and what kind of targets a particular implementation is meant to support.

I don't know of any *free* compilers that would satisfy the OP, however.

Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .

The two projects I referenced are going to be the biggest places.

formatting link
formatting link

There will be many front ends on these platforms, utilizing their C backend output engines, look through the various projects built on these platforms.

Other than those two, the most recent language that comes to mind is Google Go

formatting link

And the original C++ cfront did output C code as well.

Won't help you with the Z80, but flowcode is worth a look for ideas.

Doug McIntyre schrieb:

Isn't antlr just a parser generator like yacc?

Philipp

What exactly are you trying to do, or trying to avoid ?

just asking for 'any language' is strange....

The Z80 is going to have many compiler choices, but few that target C

- why would they ?.

When you go through another hop like this, you loose important debug coupling to your source code, and it's not clear what you gain.

The Z80 is also not likely to attract truckloads of active development ;)

An alternative would be to find an abandon-source form of the language you want, and create a C-ASM output format - that should give 'other language in', and give other-C-linking, which I am guessing is why you need C.

In the PLD realm, it is now common to see Verilog/VHDL, as low-level 'assembler' languages inside the tool chains.

If you do not need other-C-linking, just take the language native Z80 output ?

-jg

I'm not sure what you are _really_ trying to find. C++ used to be translated to c with something called cfront. Up until version 4, when growing exception handling requirements finally forced a transition to true c++ compilation to object code. cfront is largely dead, now. But that doesn't mean it wouldn't still be an option. It did a great job for what it did. Of course, I have no way to know if it meets your needs.

There's p2c for a Pascal. Klaus Bothe wrote these two papers, for example:

"Rules for the Transformation from Pascal to C," 1987 "A portable high-speed PASCAL to C Translator," 1989

I remember something called f2c, as well.

There was also RATFOR, back in my college school days, which translated a "nicer" version "rational FORTRAN" to FORTRAN II code. It was very easy to implement on your own and worked well.

And GNU compiler front ends exist, as well. Even for ADA, I believe.

Could you talk about _exactly_ what you feel you need here, and why?

Jon

I think we've got a pretty good clue that it won't meet his needs: 1KB RAM and 32KB of ROM. :)

Grant Edwards grante Yow! We are now enjoying at total mutual interaction in visi.com an imaginary hot tub ...

On Jan 12, 11:07=A0am, Grant Edwards

RAM and 32KB of ROM. =A0:)

After an initial ?!?, I took that to mean a rough application footprint, NOT the actual compiler resource needed. The OP does need to provide more info..

-jg

Writing C++ programs using cfront. I assume that was what "it" referred to. If not, then I've no idea either...

Grant Edwards grante Yow! Hey, wait at a minute!! I want a visi.com divorce!! ... you're not Clint Eastwood!!

Well, Jim also opens the possibility of talking about a hosted system. If you are suggesting that I was suggesting a cfront implementation on a target embedded system, then you and I agree there. I had been (perhaps wrongly) imagining that the translator would be implemented on some other "host" system. In such a case, cfront does a pretty good job and if a targeting c compiler would produce a small enough footprint on the embedded system, then so may also c++ filtered via cfront in many cases. I grant as fact that I know almost nothing about what the OP desires.

Jon

No, I meant that writing C++ programs using cfront (on a hosted system) sounds like a very unsuitable development methodology for a target with 1KB of RAM and 32KB of ROM. Perhaps I'm misremembering how much target overhead was involved when using cfront.

Perhaps. My recollection was that there was quite a bit of support/overhead involved with cfront, but I may be conflating cfront with something else (it was a long time ago).

I don't either...

Grant Edwards grante Yow! Four thousand at different MAGNATES, MOGULS visi.com & NABOBS are romping in my gothic solarium!!

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required