search for: nfries88

Displaying 11 results from an estimated 11 matches for "nfries88".

2011 Jun 03
1
[LLVMdev] Thinking about "whacky" backends
-------- Original Message -------- Subject: Re: [LLVMdev] Thinking about "whacky" backends Date: Fri, 03 Jun 2011 14:44:05 -0400 From: Nate Fries <nfries88 at yahoo.com> To: Joachim Durchholz <jo at durchholz.org> On 6/3/2011 1:38 PM, Joachim Durchholz wrote: > Am 01.06.2011 23:25, schrieb Nate Fries: >> That said, it seems like it ought to be possible to do the same thing >> by emitting bitcode for all supported platfor...
2011 Jun 04
0
[LLVMdev] Thinking about "whacky" backends
----- 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...
2011 Jun 02
4
[LLVMdev] Thinking about "whacky" backends
...but I'd like to have my wrapper expanded to do some more extensive functionality if somebody would like to join the project, let me know and I'll add you to the SourceForge project at http://sourceforge.net/projects/llvmlibc/ . --Sam ----- Original Message ----- > From: Nate Fries <nfries88 at yahoo.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Cc: > Sent: Wednesday, June 1, 2011 4:25 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Cameron Zwarich wrote: > >> What benefit do you get from having a b...
2011 Jun 03
2
[LLVMdev] Thinking about "whacky" backends
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
2011 Jun 03
0
[LLVMdev] Thinking about "whacky" backends
Samuel Crow <samuraileumas at yahoo.com> writes: > Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: A look at the work done on ANDF in the 90's may be helpful. I've only skimmed it but there's been some deep thinking about stuff like this. -Dave
2011 Jun 01
0
[LLVMdev] Thinking about "whacky" backends
Cameron Zwarich wrote: > What benefit do you get from having a backend here rather than an interpreter for LLVM IR? The same thing as an interpreter, just a native build (no need for an interpreter program, better speed, etc). This would be beneficial anywhere that "build once, deploy anywhere" functionality is desired, without resorting to using a higher-level language like C# or
2011 Jun 02
0
[LLVMdev] Thinking about "whacky" backends
On 6/2/2011 10:13 AM, Samuel Crow wrote: > Hi Nate, > > I've successfully ported one bitcode from Linux to Mac to Windows. All were x86 and the program was text-based, but I'd say my LLVM Wrapper would be worth some effort in the future if I could just get some help. Currently it just wraps StdIO.h with its own functions Naturally that would work perfectly fine on a similar
2011 Jun 01
4
[LLVMdev] Thinking about "whacky" backends
Am 01.06.2011 04:57, schrieb Cameron Zwarich: > What benefit do you get from having a backend here rather than an interpreter for LLVM IR? A backend that's self-sufficient and covers the entire Unixoid world. That cuts down on the number of binaries that one needs to provide for autoinstallers and such. Generated Perl could be used to bootstrap an LLVM IR interpreter, for example.
2011 Jun 03
0
[LLVMdev] Thinking about "whacky" backends
On 6/3/2011 3:19 PM, Joachim Durchholz wrote: >>>> compressing them in an archive, then decompressing and either >>>> interpreting or JIT-compiling the appropriate bitcode for the >>>> platform. This would just be a more flexible means to that same end. >>> Not sure how that is more flexible - care to elaborate? >> More flexible to the programmer,
2011 Jul 07
0
[LLVMdev] Improving Garbage Collection
On 7/6/2011 6:24 PM, Talin wrote: > The LLVM code generators and analysis passes have a much more thorough > knowledge of SSA value lifetimes than frontends do, and therefore > could avoid spilling and reloading of values when it wasn't needed. Although this would indeed be nice, it is not done by similar platforms in practice. I have investigated [very] briefly into whether the
2011 Jul 18
2
Generating OpenGL shaders from Direct3D shader bytecode
I saw on the LLVM mailing list some time ago that something like this was desired for Wine (but it was talking about an LLVM backend then). I figured I'd contact you guys to tell you that I found something like this, MojoShader by Ryan Gordon (zlib licensed). http://icculus.org/mojoshader/ http://hg.icculus.org/icculus/mojoshader/ Sorry if someone already suggested this, or if something like