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).
----- Original Message -----> From: Nate Fries <nfries88 at yahoo.com> > To: Samuel Crow <samuraileumas at yahoo.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Cc: > Sent: Friday, June 3, 2011 6:52 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > 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). >I'm not terribly fond of .NET or Java either. When I was thinking of a friendlier language, I was thinking more along the lines of http://code.google.com/p/tart/ which is already an LLVM language and designed to take advantage of all of LLVM's features internally, such as using opaque types to implement templates and eliminating the preprocessor altogether.
On 6/3/2011 8:06 PM, Samuel Crow wrote:> > > > ----- Original Message ----- >> From: Nate Fries<nfries88 at yahoo.com> >> To: Samuel Crow<samuraileumas at yahoo.com>; LLVM Developers Mailing List<llvmdev at cs.uiuc.edu> >> Cc: >> Sent: Friday, June 3, 2011 6:52 PM >> Subject: Re: [LLVMdev] Thinking about "whacky" backends >> >> 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). >> > I'm not terribly fond of .NET or Java either. When I was thinking of a friendlier language, I was thinking more along the lines of http://code.google.com/p/tart/ which is already an LLVM language and designed to take advantage of all of LLVM's features internally, such as using opaque types to implement templates and eliminating the preprocessor altogether.I read the "taste of tart" part of the wiki and didn't care for it, personally.