Re: C++ build succeeded, but with some tests failed

On Mon, Apr 14, 2008 at 4:00 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi all, > > C++ build succeeded, but with some tests failed. There were two issues that > I couldn't formally sorted, and thus I had to tweak it. I have opened > tickets for all other build related issues which have a for

Re: [perl #27243] [PATCH] Corrects (?) misleading POD & usage re: -C option.

Nigelsandever @ Btconnect . Com <[EMAIL PROTECTED]> wrote: > **"-P" (sic) > Run the "CGP" core. It should be 'C'. Thanks, fixed. [ please provide patches with full pathnames relative to parrot root ] leo

[perl #27243] [PATCH] Corrects (?) misleading POD & usage re: -C option.

# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #27243] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27243 > Changes 2 lines (marked ** below) in t\harness to correct errors in the POD and

Re: c-style assembly in .pasm

Tupshin Harper wrote: In my ongoing quest to understand the possibilities (and possible limitations) of parrot, here's another one. ;-) How close a mapping can there be between regular (x86 in this example) assembly (as generated by c-compilation) and pasm? I can't figure out if the stack ops ca

Re: C#/Parrot Status

On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote: > Nicholas Clark wrote: > >Is there any speed advantage in truncating by casting via a C type > >[eg a = (int)(short) b] > >rather than and on a bitmask > >[eg a = b & 0x] > >? > > > gcc uses MOVSX (movs{b,w}l), move byte/word

Re: What dotgnu.ops does (Re: C#/Parrot Status)

Gopal V wrote: inline op conv_u1_ovf(inout INT) { - if($1 >= 0 && $1 <= 256 ) { + if($1 >= 0 && $1 <= 255 ) { Thanks, applied leo

Re: C#/Parrot Status

Nicholas Clark wrote: (do all the unsigned with masks) Yep And we ought to make a generic "safe" version of the code for signed truncation that works for platforms that are any or all of the following holds I tried this one: inline op conv_i1(inout INT) { #if 1 INTVAL x = $1; x <<=

Re: C#/Parrot Status

On Mon, 2002-11-25 at 11:04, Nicholas Clark wrote: > Is there any speed advantage in truncating by casting via a C type > [eg a = (int)(short) b] > rather than and on a bitmask > [eg a = b & 0x] > ? > > We're going to have to do that latter to make it work on Crays anyway Why? -- Bryan C.

Re: C#/Parrot Status

Nicholas Clark <[EMAIL PROTECTED]> writes: > (doing stuff on out of range signed values is undefined behaviour, IIRC) Yes, that's right. Some GCC optimizations rely on the fact that signed integer calculations can never overflow.

What dotgnu.ops does (Re: C#/Parrot Status)

If memory serves me right, Gopal V wrote: > I couldn't make myself name it "dotnet".ops so named it dotgnu.ops ... On nicholas' advice I'm writing out the expected results for all these opcodes... in the hope that someone more well versed in writing ..t files than me can help .. conv_i1 & conv_i1

Re: C#/Parrot Status

I guess I have more to learn about writing opcodes for parrot ... But all I can say is you people make it almost too easy :-) If memory serves me right, Leopold Toetsch wrote: > The INTVAL could be a "long long". Ok ... /me sort of needs an Int32 there ... > Parrot_Int2 will be generated by a t

Re: C#/Parrot Status

On Mon, Nov 25, 2002 at 05:40:36PM +0100, Leopold Toetsch wrote: > Nicholas Clark wrote: > > I'm surprised that you did your regression tests longhand, rather than having > > a data table in perl of input and expected output, and auto-generating parrot > > code. > > > Writing a few explicit test

Re: C#/Parrot Status

On Mon, Nov 25, 2002 at 04:39:23PM +, Nicholas Clark wrote: > And we ought to make a generic "safe" version of the code for signed > truncation that works for platforms that are any or all of the following > holds > > 1: no type of that size (eg Crays) > 2: signed integer truncation (UTS) [and

Re: C#/Parrot Status

Nicholas Clark wrote: On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote: Gopal V wrote: /* ** dotgnu.ops */ Thanks applied, I'm surprised that you did your regression tests longhand, rather than having a data table in perl of input and expected output, and auto-generating

Re: C#/Parrot Status

On Mon, Nov 25, 2002 at 11:29:01AM -0500, Dan Sugalski wrote: > At 4:04 PM + 11/25/02, Nicholas Clark wrote: > >Is there any speed advantage in truncating by casting via a C type > >[eg a = (int)(short) b] > >rather than and on a bitmask > >[eg a = b & 0x] > >? > > > >We're going to have

Re: C#/Parrot Status

On Mon, 25 Nov 2002, Leopold Toetsch wrote: > Dan Sugalski wrote: > > >> $1 = (INTVAL)((char)($1)); > >> The INTVAL could be a "long long". > > > > That one needs a sizeof(char) check. chars are *not* 8 bits everywhere. > > AFAIK are chars 8 bits by defintion, i.e. C standard. The machine > repr

Re: C#/Parrot Status

At 4:04 PM + 11/25/02, Nicholas Clark wrote: On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote: Gopal V wrote: > /* > ** dotgnu.ops > */ Thanks applied, I'm surprised that you did your regression tests longhand, rather than having a data table in perl of input and expec

Re: C#/Parrot Status

At 5:01 PM +0100 11/25/02, Leopold Toetsch wrote: Dan Sugalski wrote: $1 = (INTVAL)((char)($1)); The INTVAL could be a "long long". That one needs a sizeof(char) check. chars are *not* 8 bits everywhere. AFAIK are chars 8 bits by defintion, i.e. C standard. The machine representation o

Re: C#/Parrot Status

Dan Sugalski wrote: $1 = (INTVAL)((char)($1)); The INTVAL could be a "long long". That one needs a sizeof(char) check. chars are *not* 8 bits everywhere. AFAIK are chars 8 bits by defintion, i.e. C standard. The machine representation of a char might be different though. Same here. s

Re: C#/Parrot Status

On Mon, Nov 25, 2002 at 04:51:05PM +0100, Leopold Toetsch wrote: > Gopal V wrote: > > > /* > > ** dotgnu.ops > > */ > > Thanks applied, I'm surprised that you did your regression tests longhand, rather than having a data table in perl of input and expected output, and auto-generating parrot code

Re: C#/Parrot Status

Gopal V wrote: /* ** dotgnu.ops */ Thanks applied, leo PS please run "perl Configure.pl" after applying.

Re: C#/Parrot Status

At 3:58 PM +0100 11/25/02, Leopold Toetsch wrote: Gopal V wrote: Thanks for the patch. I'll add some config methods and apply it after polishing. DISCLAIMER: I don't know anything about how parrot opcodes should be written .. So all errors are accidental and I would like somebody to point them

Re: C#/Parrot Status

Gopal V wrote: Thanks for the patch. I'll add some config methods and apply it after polishing. DISCLAIMER: I don't know anything about how parrot opcodes should be written .. So all errors are accidental and I would like somebody to point them out to me .. Pretty well done, modulo minor typ

Re: C#/Parrot Status

If memory serves me right, Rhys Weatherley wrote: > on 32-bit, 64-bit, and native-sized integer types (8-bit > types don't need it). Hmm... maybe there's only one way to stop this lng thread ... Oct 18 20:31:20 no, no, you have it wrong. you don't *ask* us t

Re: C#/Parrot Status

At 10:55 AM +1000 11/25/02, Rhys Weatherley wrote: Nicholas Clark wrote: Floating point fills me with fear. If it makes you feel better, C# does not require overflow detection on floating-point operations. FP overflow results in +/-INF, underflow results in zero, and undefined is NAN. Only

Re: C#/Parrot Status

Nicholas Clark wrote: > Floating point fills me with fear. If it makes you feel better, C# does not require overflow detection on floating-point operations. FP overflow results in +/-INF, underflow results in zero, and undefined is NAN. Only integer overflow detection is required, and then only

Re: C#/Parrot Status

On Sun, Nov 24, 2002 at 10:33:23PM +0100, Florian Weimer wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > .NET has exception-throwing versions of its math operations. If you do > > an add of two 8-bit integers and the result overflows, you should get > > an exception (if you've used the "ch

Re: C#/Parrot Status

At 10:33 PM +0100 11/24/02, Florian Weimer wrote: Dan Sugalski <[EMAIL PROTECTED]> writes: .NET has exception-throwing versions of its math operations. If you do an add of two 8-bit integers and the result overflows, you should get an exception (if you've used the "check overflow" versions of

Re: C#/Parrot Status

Dan Sugalski <[EMAIL PROTECTED]> writes: > .NET has exception-throwing versions of its math operations. If you do > an add of two 8-bit integers and the result overflows, you should get > an exception (if you've used the "check overflow" versions of the ops) Actually, I thought about implementing

Re: C#/Parrot Status

At 8:07 PM +0100 11/24/02, Leopold Toetsch wrote: Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? Sorry for the ignorant question: This

Re: C#/Parrot Status

Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? Sorry for the ignorant question: This does mean what and implying that and whatsoever?

Re: C#/Parrot Status

At 1:46 PM +0100 11/24/02, Florian Weimer wrote: "Iacob Alin" <[EMAIL PROTECTED]> writes: This might be a stupid question, but are this datatypes going to be PMCs? And a related question: What about trapping integer arithmetic? That'll be done with the standard exception handling mechanism

Re: C#/Parrot Status

"Iacob Alin" <[EMAIL PROTECTED]> writes: > This might be a stupid question, but are this datatypes going to be > PMCs? And a related question: What about trapping integer arithmetic?

Re: C#/Parrot Status

If memory serves me right, Leopold Toetsch wrote: > > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on stack > > > truncate to [-128..127]? And why the push? IL is a fully stack language ... pop int32, trunc, push int8 ... Yes,

Re: C#/Parrot Status

Leopold Toetsch wrote: > > If memory serves me right, Leopold Toetsch wrote: > >^^^... > > Your mailer should know ;-) That's his mailer talking. It always does that. :-) > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on

Re: C#/Parrot Status

On Mon, 18 Nov 2002, Iacob Alin wrote: > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on stack > > conv.i2 Convert to int16, pushing int32 on stack [etc.] > This might be a stupid question, but are this datatypes going to be PMCs? It's a ve

Re: C#/Parrot Status

Iacob Alin wrote: This might be a stupid question, but are this datatypes going to be PMCs? Only types bigger then our current native types: INTVAL typically 32 bit long on 32 bit machines FLOTVAL typically double Alin leo

Re: C#/Parrot Status

Gopal V wrote: If memory serves me right, Leopold Toetsch wrote: ^^^... Your mailer should know ;-) Hmm... I guess I can only quote the ECMA spec here ... conv.i1 Convert to int8, pushing int32 on stack truncate to [-128..127]? And why the push? What is the behaviour on overflow? co

Re: C#/Parrot Status

Gopal V said: > If memory serves me right, Leopold Toetsch wrote: > > > Please have a look at include/parrot/datatypes.h. I hope that there are > > all types you'll need. > > It seems so ... but I'm not really certain about Float data types ... > > > Can you specify, what opcodes you would need? >

Re: C#/Parrot Status

If memory serves me right, Leopold Toetsch wrote: > Please have a look at include/parrot/datatypes.h. I hope that there are > all types you'll need. It seems so ... but I'm not really certain about Float data types ... > Can you specify, what opcodes you would need? Hmm... I guess I can only q

Re: C#/Parrot Status

Rhys Weatherley wrote: I've been working on some other stuff lately, so this is the first opportunity I've had to catch up on Parrot. I'm interested in the current status of the following within Parrot: - object/class support - fixed-sized integers and/or conversion opcodes - embedding

Re: C# and Parrot

Bryan C. Warnock sent the following bits through the ether: > Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe > for floating point numbers? For the JVM: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#19511 "The floating-point types are float and

Re: C# and Parrot

At 7:21 PM +0530 10/20/02, Gopal V wrote: If memory serves me right, Bryan C. Warnock wrote: > It looks like we're going to need 8,16,32,64 bit types... Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? IL (Ecma-335) -- 134.

Re: C# and Parrot

Dan Sugalski wrote: > I think so. I'm going to add in some conversion ops for the shorter > float forms, and for the partial-sized integers. I'm unsure at the > moment whether I want to commit to full 64 bit integers in I > registers. On the one hand it means a lot more can be done at the low > le

Re: C# and Parrot

"Bryan C. Warnock" wrote: > Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe > for floating point numbers? The CLI has three floating point types, of which 2 are visible to C# and a third is used by the engine. These are "float32", "float64", and "native float". The firs

Re: C# and Parrot

If memory serves me right, Bryan C. Warnock wrote: > > It looks like we're going to need 8,16,32,64 bit types... > > Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe > for floating point numbers? IL (Ecma-335) -- 134.1.1 Floating Point 14 The floa

Re: C# and Parrot (dotgnu meeting)

If memory serves me right, Leon Brocard wrote: > It looks like the DotGNU weekly IRC meeting will be discussing > Parrot. Could be interesting: > http://www.dotgnu.org/pipermail/developers/2002-October/008345.html A condensed summary of the IRC meetings have been posted as :- http://www.dotgnu.org

Re: C# and Parrot

Leon Brocard sent the following bits through the ether: > It looks like the DotGNU weekly IRC meeting will be discussing > Parrot. Could be interesting: It was quite interesting. I managed to make it to the early one and Dan to the later one. An "annotated and abridged chatlog" is available: http

Re: C# and Parrot

On Sun, 2002-10-20 at 07:39, Leon Brocard wrote: > Leon Brocard sent the following bits through the ether: > > > It looks like the DotGNU weekly IRC meeting will be discussing > > Parrot. Could be interesting: > > It was quite interesting. I managed to make it to the early one and > Dan to the la

Re: C# and Parrot

At 1:38 PM +0100 10/18/02, Simon Cozens wrote: [EMAIL PROTECTED] (Rhys Weatherley) writes: int x = ...; int y = (short)x; The value of x is truncated to 16 bits, and then sign-extended to int. I'm looking for something like the "conv.i2" instruction in IL, or "i2s" in JVM. One co

Re: C# and Parrot

Rhys Weatherley wrote: Leopold Toetsch wrote: [ imcc ] Yes, I saw that. I haven't yet decided whether to generate pasm or imcc directly from cscc. I did have some problems getting "test_spilling.imc" to work. Is this a known issue? Now yes ;-) Last cleanup changes did break the spillin

Re: C# and Parrot

On Fri, Oct 18, 2002 at 05:54:08PM +0100, Leon Brocard wrote: > It looks like the DotGNU weekly IRC meeting will be discussing > Parrot. Could be interesting: > http://www.dotgnu.org/pipermail/developers/2002-October/008345.html The author of that mail needs to learn the difference between GMT and

Re: C# and Parrot

At 5:54 PM +0100 10/18/02, Leon Brocard wrote: Rhys Weatherley sent the following bits through the ether: DotGNU is currently reaching out to other projects in the OSS/FS world to see how we can help you and how you might be able to help us. It looks like the DotGNU weekly IRC meeting will

Re: C# and Parrot

Rhys Weatherley sent the following bits through the ether: > DotGNU is currently reaching out to other projects in the OSS/FS > world to see how we can help you and how you might be able to > help us. It looks like the DotGNU weekly IRC meeting will be discussing Parrot. Could be interesting: htt

Re: C# and Parrot

On Fri, 18 Oct 2002, Rhys Weatherley wrote: > Leopold Toetsch wrote: > > > > What is the size of the "int" type? Will it always be 32 bit > > > or is it "whatever is best for the machine"? > > > > It's a Configure option. > > That may be a bit of a problem, as C# (and Java for that matter) > i

Re: C# and Parrot

[EMAIL PROTECTED] (Rhys Weatherley) writes: > int x = ...; > int y = (short)x; > > The value of x is truncated to 16 bits, and then sign-extended > to int. I'm looking for something like the "conv.i2" instruction > in IL, or "i2s" in JVM. One concievable way to do that is basically have

Re: C# and Parrot

Brent Dax wrote: > # I'm a bit confused as to how one creates a user-defined class > # in Parrot, and makes virtual method calls, accesses fields, > # and what-not. I can't seem to find a good example (Cola does > # non-virtual methods only at present). > > You don't, at least not yet. Eventual

Re: C# and Parrot

Leopold Toetsch wrote: > Have a look at imcc, which is our high level assembler. imcc does > register allocation and (currently little) optimization. perl6 produces > IMCC code. imcc can also run the code or write PBC files. Yes, I saw that. I haven't yet decided whether to generate pasm or imcc

Re: C# and Parrot

Rhys Weatherley sent the following bits through the ether: > The Portable.NET C# compiler, cscc, is very extensive, and is > capable of generating output for multiple bytecode formats (IL > and JVM are currently supported, more or less). Oh, excellent. If you're already targeting both then it sho

Re: C# and Parrot

Rhys Weatherley wrote: The Portable.NET C# compiler, cscc, is very extensive, and is capable of generating output for multiple bytecode formats (IL and JVM are currently supported, more or less). Have a look at imcc, which is our high level assembler. imcc does register allocation and (curre

RE: C# and Parrot

Rhys Weatherley: # I'm Rhys Weatherley, the author of Portable.NET, which is # part of the DotGNU project. (Put down that flame thrower! I # come in peace. :-) ) Hey. Don't worry--we're not worried about DotGNU. On the other hand, if you said you were on the actual .Net development group, it

Re: C Garbage collector

Almost every GC algorithm has its advantages and disadvantages. Real-time gc normally carry high cost, both in memory and in cpu time. I believe that options is very important. We should make Perl 6 runtime compaible with multiple gc schemes, possibly including reference counting. However, it wil

Re: C Garbage collector

Do you folks know anything about the garbage collector in rScheme http://www.rscheme.org/>? They say it's got a "real time generational" garbage collector. It must be worth looking over. -- mailto: (Karl M. Hegbloom) [EMAIL PROTECTED] http://www.microsharp.com phone://USA/WA/360-260-2066

RE: C Garbage collector

Dear Hong, This was actually a reply to a posted link for a C/C++ replacement GC (http://www.hpl.hp.com/personal/Hans_Boehm/gc/), not the default GC from any particular C package. Grant M.

Re: C Garbage collector

mark sweep collector or semi space copy collector. There is no advantage to use C garbage collector. Hong - Original Message - From: "NeonEdge" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 21, 2001 3:32 AM Subject: RE: C Garbage collector >

RE: C Garbage collector

I agree with Damien that the Sun description sounds less portable, which we all know in the Perl world is crucial (>80 ports)(although Sun mentions 16-bit DOS/Win). Any GC implementation needs to try to 'not break' the existing stuff. Other questions are somewhat dependent upon what language is us

Re: C Garbage collector

On Wed, 21 Feb 2001, Alan Burlison wrote: > Alan Burlison wrote: > > > I've attached the HTML > > Well it was there when I sent it... does this list strip attachments or > something? yes, it does. It is usually just misconfigured mailers or spam. -- ask bjoern hansen -

Re: C Garbage collector

On Wed, Feb 21, 2001 at 12:25:10AM +, Alan Burlison wrote: > Shame it only works with the Sun compilers. See also Boehm's garbage collector, which is rather more portable: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ "The collector uses a mark-sweep algorithm. It provides incremental

Re: C Garbage collector

Alan Burlison wrote: > I've attached the HTML Well it was there when I sent it... does this list strip attachments or something? Here is is as badly-formatted text - sorry! Alan Burlison Appendix A: How Sun WorkShop Memory Monitor Works Memory management in C/C++ is both time consuming an

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 tha

RE: C# (.NET) has no interpreters

t 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] |

Re: C--

John Tobey wrote: > > My quickie summary seems to be inaccurate. The lcc thing is not an > implementation, it's a C-- code generator (why??). The "lcc thing" is a C to C-- translator that serves two purposes: to demonstrate how one might employ C-- as a back-end, and to provide an abundant sourc

Re: C--

John Tobey <[EMAIL PROTECTED]> wrote: > Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > > A few more clicks and I found: > > > > http://www.cminusminus.org/ > > Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free > (non-DFSG-compliant) complete. Others in progress. My quickie

Re: C--

Nick Ing-Simmons <[EMAIL PROTECTED]> wrote: > John Tobey <[EMAIL PROTECTED]> writes: > >Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > >> A few more clicks and I found: > >> > >> http://www.cminusminus.org/ > > > >Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free > >(non-DFSG

Re: C--

John Tobey <[EMAIL PROTECTED]> writes: >Joshua N Pritikin <[EMAIL PROTECTED]> wrote: >> A few more clicks and I found: >> >> http://www.cminusminus.org/ > >Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free >(non-DFSG-compliant) complete. Others in progress. > >Why not specif

Re: C# (.NET) has no interpreters

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

RE: C# (.NET) has no interpreters

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 >

Re: C--

On Thu, Aug 03, 2000 at 11:30:40AM -0400, [EMAIL PROTECTED] wrote: > I'm not sure about this one. My odds-on favorite answer: Picture some > M$ hackers telling their supervisor they are working on some GCC > enhancements. But how do you explain the fact that S. P. Jones uses Latex and cygwin?

Re: C--

Kevin Scott <[EMAIL PROTECTED]> wrote: > John Tobey wrote: > > > > Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free > > (non-DFSG-compliant) complete. Others in progress. > > > > Why not specify as a C extension: I'm still looking for that. > > > > -John > > Technical answ

Re: C--

John Tobey wrote: > > Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free > (non-DFSG-compliant) complete. Others in progress. > > Why not specify as a C extension: I'm still looking for that. > > -John Technical answer: C-- has lots of features that would be difficult to ha

Re: C--

On Thu, Aug 03, 2000 at 10:33:25AM -0400, [EMAIL PROTECTED] wrote: > ... Quickie summary. Implementations: one[1] semi-free > (non-DFSG-compliant) complete. Others in progress. > > Why not specify as a C extension: I'm still looking for that. The following paper is recommended over the one pos

Re: C--

Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > A few more clicks and I found: > > http://www.cminusminus.org/ Thanks, Joshua. Quickie summary. Implementations: one[1] semi-free (non-DFSG-compliant) complete. Others in progress. Why not specify as a C extension: I'm still looking for that.

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.

Re: C# (.NET) has no interpreters

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

Re: C# (.NET) has no interpreters

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

Re: C# (.NET) has no interpreters

> > 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

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 chi

Re: C# (.NET) has no interpreters

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

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):

Re: C# (.NET) has no interpreters

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