search for: whacki

Displaying 20 results from an estimated 46 matches for "whacki".

Did you mean: whack
2011 Jun 01
2
[LLVMdev] Fw: Thinking about "whacky" backends
Sorry, forgot to CC the list. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Joachim Durchholz <jo at durchholz.org> > Cc: > Sent: Tuesday, May 31, 2011 9:35 PM > Subject: Re: [LLVMdev] Thinking about "whacky" backends > > Hello, > > > ----- Original Message ----- >> From: Joachim Durchholz
2011 Jun 01
5
[LLVMdev] Thinking about "whacky" backends
I've been tossing around some ideas about high-level backends. Say, have LLVM emit Perl code. Sounds whacky but isn't. It's good for the first bootstrapping phase in environments where you don't have a C compiler, where you don't have a cross-compiled binary for download, but you can execute Perl. It also makes a great inspect-the-sources-with-an-editor stage for aspiring
2011 Jun 01
0
[LLVMdev] Fw: Thinking about "whacky" backends
On May 31, 2011, at 7:36 PM, Samuel Crow wrote: <snip> >> >> Now my idea for a whacky backend: Just a wrapper of the bitcode writer with its >> own special target triple: bitcode-tarrget-neutral and a generic data layout >> that aligns to single bytes as a placeholder only. It should disallow >> overriding the alignment of individual instructions to avoid
2004 Jan 09
2
Broken DNS makes Asterisk whacky!
Check this out. I recently closed a bug I had written, #495 "ExtraChannel in transfer causes crash" Now I've been able to reproduce it, and somewhat narrowed down the culprit. But before I write another bug report, I wanted to see if anyone else had experienced the following (or would like to try:) When DNS (or outside connection to the network, not sure which) is broken and
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 Sun's has had notable performance
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
2011 Jun 01
0
[LLVMdev] Thinking about "whacky" backends
What benefit do you get from having a backend here rather than an interpreter for LLVM IR? Cameron On May 31, 2011, at 5:30 PM, Joachim Durchholz wrote: > I've been tossing around some ideas about high-level backends. > > Say, have LLVM emit Perl code. > > Sounds whacky but isn't. It's good for the first bootstrapping phase in > environments where you don't
2011 Jun 03
1
[LLVMdev] Thinking about "whacky" backends
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 platform/arch combinations Wait... is bitcode not platform-agnostic? I thought it is. > and > compressing them in an archive, then decompressing and either > interpreting or JIT-compiling the appropriate bitcode 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
2
[LLVMdev] Fw: Thinking about "whacky" backends
On Wed, Jun 1, 2011 at 12:53 PM, Henry Mason <thefridgeowl at gmail.com> wrote: > This is pretty much what's happening with Portable Native Client, right? > > http://www.chromium.org/nativeclient/pnacl > > See also the first presentation from the November LLVM meeting: http://llvm.org/devmtg/2010-11/ PNaCl fixes data layout to be just "portable enough" to cover
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
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 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 02
4
[LLVMdev] Thinking about "whacky" backends
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. Here's some of what it would take to make portable bitcodes in C or LLVM Assembly: * Convert all
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.
2020 Mar 26
2
making sense of the stats
I can't make sense of the connection stats on the admin page. We have one source and one mountpoint. What is the difference between _client_connections_ and _clients_ and _connection_s? How can they be so different in value? Same questions for _listener_connections_ and _listeners_? The connections values seem high for only 5 listeners and one admin. Here is a snapshot of the admin
2008 May 22
1
Plotting a Quadratic...
I have an equation describing the best-fit model for a set of points (just 2 axes) that is in the form: y=b+mx+px^2 Where b is the intercept, m is the slope describing a linear term, and p is a slope of the quadratic term. I would like to plot this equation on a curve (I know the equation is y=(.1766x^2)+(.171x)+.101) on the original scatterplot. Any easy way to plot this equation and
2002 Oct 31
1
winelib: porting Delphi apps
Just a (probably crazy) thought: What about porting Windoze apps that aren't written in C? I've got a Delphi application that currently runs under Virtual PC under OS 9.2 on an eMac (PPC Processor), which would run much faster without those OS layers in between. I don't really have a clue as to whether this really far-out-whacky or not cuz I am not really a Delphi, or, for that matter,
2005 Sep 30
2
klibc loader crash...
Hi all, I've a simple program called empty.c :) $ cat empty.c int main(int argc, char* argv[]) { return 0; } $ cat empty410.s .file "empty.c" .text .p2align 4,,15 .globl main .type main, @function main: xorl %eax, %eax ret .size main, .-main .ident "GCC: (GNU) 4.1.0 20050922 (experimental)"