RE: C# (.NET) has no interpreters
http://www.cminusminus.org/ has pointers to three implementations. None are 'industrial strength' yet. 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. But you can do it inefficiently, as the Trampoline C-- compiler does (see the above URL for pointer to it). Simon | -Original Message- | From: Joshua N Pritikin [mailto:[EMAIL PROTECTED]] | Sent: 03 August 2000 15:01 | To: Simon Peyton-Jones | Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; | [EMAIL PROTECTED] | 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 tackle native code generation using C as the |intermediate language instead of a JIT. | | Oh, yah. C is the obvious choice, but it doesn't have to | be the only | backend. In theory we could also generate C#'s IL. Or C--. | | Help. I'm only halfway through the C-- paper, and I'm wondering: | What is the status of implmentations? Why not implement it as | extensions to existing C compilers? | | Simon, can you comment? | | -- | Never ascribe to malice that which can be explained by stupidity. |(via, but not speaking for Deutsche Bank) |
Re: C# (.NET) has no interpreters
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 that it can get structs and typedefs right, and preferably also inline functions. It would have to discriminate and reject "ill-behaved" C constructs. I was not thinking of implementing C-- "on top of" C; certainly not on top of ANSI C. But I could imagine a (Perl?) program that translates C-- into asm-ified C without C function calls. All you'd really need are a few primitives for getting and setting the sp and ip, a list of the registers, and some macros for inserting span metadata into a different linker section. All of this would be straightforwardly implemented with GCC using a smallish machine-specific header. I'll bet a non-optimizing version could be produced with no asm - just use volatile for variables and goto for jumps. Accessing the stack pointer and inserting span data might require asm. Best -John -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: C# (.NET) has no interpreters
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): | Kaffe's current performance, despite the fact that Kaffe features a JIT | compiler, is rather weak. While we do not have hard data, we would | estimate that Kaffe performs about as good or only slightly better than | the JDK 1.1.7 interpreter on a platform such as Linux. | Kaffe's Just-in-time compiler does not perform any | optimizations. This leads to a large number of emitted machine | code instructions per bytecode instruction, many of them | unnecessary and expensive loads and stores. 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 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 want to go? On the other hand, compile-time variable typing seems eminently relevant. There are several threads trying to tackle this problem right now. I'm starting to think that mailing lists are poor substitutes for face-to-face brain storming. - Ken
Re: C# (.NET) has no interpreters
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 chip architecture perl runs on, this is a daunting task, and I don't think it should be a target for the core development. Alternate backend, sure, but not a primary target. We might want to leave that to the various OS vendors for now. Most of 'em handle the high-performance JITs for their systems, and perl's as important in some ways as Java. Besides, I can guarantee that the folks in Dec engineering know the Alpha far better than anyone else we have handy does, and the same can probably be said for the other chips. (Well, we've got Jeff from HP and Alan from Sun, but they count as vendor folks...) Dan
