[LLVMdev] Thinking about "whacky" backends

[Nate Fries]

On 6/3/2011 3:19 PM, Samuel Crow wrote:
> Why not runtime checks?  The constant folding and dead-code elimination passes would get rid of any redundant code in a later stage of compilation anyway.  The important part, as I see it, is that LLVM already does constant folding and dead-code elimination.  Meta-data might require more effort in the long run.
>
> --snip--
Less flexible for the programmer and it differs from normal accepted 
practice, which is almost always a terrible thing.

> There are already many MANY wrappers for OS functionality out there.  SImply choosing some of the more popular ones like wxWidgets, OpenAL Soft and Irrlicht should make the job easier.  The hardest parts would be converting all of the preprocessor macros into the new function one way or the other, whether it be metadata or runtime checks to constant booleans, and converting the runtimes and build environments to use the new wrapper.
None of these are all-encompassing and it is not practical to make them 
such. Sometimes the differences are just too large.
What you are suggesting is no different from your original suggestion, 
besides that you're stripping even more control from the programmer by 
forcing the use of things like Irrlicht and OpenAL.
> If we're going to make a superset of C++, why not ditch C++ outright and just write a code converter to a friendlier high-level language.  Sorry if I'm not making much headway with you right now but I'm just trying to save work by using existing code wherever possible to save work.
Most JVMs perform terribly. Even Sun's has had notable performance 
issues in my experience.
.NET is an excellent case, but then that's only available on Microsoft 
systems and from numerous benchmarks I've found, Mono is a weak 
substitute. If you're suggesting that we go the other way around (build 
native code from a high-level language, as opposed to using native code 
initially) then that's a terrible idea for myself personally. I lack 
familiarity with CLR-based languages and absolutely detest some things 
about Java; I would rather stick with good ol' C++. I prefer 
strongly-typed languages, so ECMAScript and most other standardized 
high-level languages are less than desirable for me.

I would much prefer my original suggestion, which is very simple as well 
and would require even less code than the conversions you're suggesting 
(and the only additional dependency being an archiving library).