Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> You can't really implement C-- on top of C efficiently, because of
> (a) tail calls and (b) the runtime interface for garbage collection,
> exception handling etc.
Agreed. But any practical C-- implementation will start with a C/C++
compiler so tha
Subject: Re: C# (.NET) has no interpreters
|
|
| On Thu, Aug 03, 2000 at 09:32:10AM -0400,
| [EMAIL PROTECTED] wrote:
| > Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
| > > On Wed, Aug 02, 2000 at 07:30:23PM -0400, [EMAIL PROTECTED] wrote:
| > > > I'd prefer us to
Kevin Scott wrote:
> Some of the difficulties they had when using C as the back-end for
> functional languages (like Haskell) were:
Appel has said that ML reclaims about 98% of the heap every time
it collects. Functional languages have such a different model that
it doesn't surprise me that C isn
ailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 02, 2000 10:17 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: C# (.NET) has no interpreters
>
>
> > > While C might be fine and dandy for getting o.k. native
> code w/o too
>
On Thu, Aug 03, 2000 at 09:32:10AM -0400, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 02, 2000 at 07:30:23PM -0400, [EMAIL PROTECTED] wrote:
> > > I'd prefer us to tackle native code generation using C as the
> > > intermediate language instead of a JIT.
Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 02, 2000 at 07:30:23PM -0400, [EMAIL PROTECTED] wrote:
> > Joshua N Pritikin wrote:
> > > perl5 is interpreter-centric with native code generation
> > > bolted on well into the development lifecycle.
> >
> > I'd prefer us to tackle native
On Wed, Aug 02, 2000 at 07:30:23PM -0400, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin wrote:
> > perl5 is interpreter-centric with native code generation
> > bolted on well into the development lifecycle.
>
> I'd prefer us to tackle native code generation using C as the
> intermediate language i
> > While C might be fine and dandy for getting o.k. native code w/o too
> > much implementation effort, I think that it might be worth the effort
> > to implement a JIT compiler for the perl interpreter's intermediate
> > language.
Speaking of intermediate languages, is there any more concrete i
On Wed, 2 Aug 2000, Kevin Scott wrote:
> While C might be fine and dandy for getting o.k. native code w/o too
> much implementation effort, I think that it might be worth the effort
> to implement a JIT compiler for the perl interpreter's intermediate
> language.
Given the number of OSes and chi
Ken Fox wrote:
>
> I'd prefer us to tackle native code generation using C as the
> intermediate language instead of a JIT. It's more portable, simpler
> and takes advantage of all the C compiler optimizations. I'm not
> looking for Perl 6 to be a Java/Applet replacement. Is that really
> where we
Joshua N Pritikin wrote:
> Of course perl6 can retain both execution models (op-tree & native
> code), but perhaps the emphasis should be on optimized native code.
The Kaffe java VM uses a native code JIT and they've had trouble
getting decent performance. From their own web page (www.kaffe.org):
On Wed, Aug 02, 2000 at 09:01:18PM +0100, [EMAIL PROTECTED] wrote:
> On Wed, Aug 02, 2000 at 12:20:00PM -0600, Nathan Torkington wrote:
> > Ken Fox writes:
> > > pipeline stalls, cache misses and a whole bunch of interesting things. One
> > > of the reasons Perl performed well is that it spent a l
12 matches
Mail list logo
