1. C Compilers
- Posted by axtens_bruce Feb 08, 2023
- 1379 views
According to the documentation, "The Translator currently works with GNU C on Unix-like OSes, GNU C on Windows from MinGW or Cygwin using the -gcc option and with Watcom C (the default) on Windows. These are all free compilers."
Given that Visual Studio has, for some years now, been free to use (via the Community version), is targeting the command line compiler a bridge too far?
-Bruce
2. Re: C Compilers
- Posted by ghaberek (admin) Feb 09, 2023
- 1305 views
There have been a few attempts to support Microsoft's compilers but as it stands we're depending on a few GCC-specific features. I don't think it's impossible but more work needs to be done to clean up the build process (which is a mess) and the translator so that it produces "portable" code. Hypothetically, if the translated code is portable enough, we could use nearly any compiler. I've even experimented with TCC which would be nice to bundle with Euphoria.
-Greg
3. Re: C Compilers
- Posted by axtens_bruce Feb 10, 2023
- 1214 views
we're depending on a few GCC-specific features.
So I've just noticed. There's a workaround for __attribute__ discussed on StackOverflow.
In my ample spare time (NOT!) I may play with postprocessing the code for CL to compile.
-Bruce
4. Re: C Compilers
- Posted by axtens_bruce Feb 13, 2023
- 1066 views
I've just noticed that Zig offers an inbuilt C/C++ compiler. Under the hood, I think they're targeting Clang. Any appetite for targeting LLVM?
5. Re: C Compilers
- Posted by ghaberek (admin) Feb 14, 2023
- 966 views
I've just noticed that Zig offers an inbuilt C/C++ compiler. Under the hood, I think they're targeting Clang. Any appetite for targeting LLVM?
Oh I've considered it several times. But LLVM is huge and somebody needs to better streamline the scan-parse-execute cycle to make it easier to hook into the process. Plus there's the concern of having to build and bundle the bits of LLVM required for creating executables. Right now it's sort-of modular which is how the interpreter and translator use the same front end (almost) but output very different results. Hypothetically if that process were made a bit more modular, any number of "back ends" could be attached a la LLVM and its architecture. The phrase I've used in the past is "I want to take Euphoria code, chew it up, then spit it out." But a big benefit of using LLVM would be targeting an almost limitless number of platforms and architectures.
-Greg
6. Re: C Compilers
- Posted by axtens_bruce Feb 15, 2023
- 950 views
Oh I've considered it several times.
It's just that it is, like getting euc to also compile OCaml and COBOL, a SMOP (Small Matter Of Programming). And it's not like you're overwhelmed by an army of programmers wanting to help.
-Bruce
7. Re: C Compilers
- Posted by axtens_bruce Mar 01, 2023
- 854 views
Something else to consider GCC Tiny which I just saw on Reddit's ProgrammingLanguages
LATER
Hang on, isn't this what we're doing anyway??
-Bruce
8. Re: C Compilers
- Posted by ghaberek (admin) Mar 01, 2023
- 782 views
Something else to consider GCC Tiny which I just saw on Reddit's ProgrammingLanguages
That's an interesting project! Good to see a how ground-up implementation comes together. You don't see that very often.
Hang on, isn't this what we're doing anyway??
That project is creating a custom front end for GCC which binds itself directly on top of the GCC back end then ingests its "tiny" code and spits out executable code. The Euphoria translator emits C code and then calls vanilla GCC to compile it (or emits a Makefile and we run that to call GCC). But yes one way or another, I think it would be worthwhile to make the translator compile in memory (however that happens) and output an executable without all the intermediate C files.
-Greg
