On Wed, 21 Aug 2002, 'John Porter' wrote: > Sean O'Rourke wrote: > > However, if we already have a working register > > allocator and peephole optimizer, I see little reason to write another. > > Maybe you're taking a very perl6-centric view. (I don't know.)
I usually tend to do so, but I'm not sure that I did in this case. My impression was that IMCC would mostly do low-level things for which there's basically one right way. Hopefully most language-dependent things would happen at a higher level. Unless IMCC's quality/time tradeoff isn't right for your Tcl compiler (hypothetically speaking, of course...), I'd be surprised if it didn't suit. And if it doesn't maybe it should be changed so it does. Melvin? > > > >While imcc is cool and worthy, it probably oughtn't be discussed on > > > >this list untless/until it is a "blessed" member of the parrot suite. > > > > As opposed to the blessed BASIC and Befunge? > > No. Basic, befunge, et alia exist as "standard proofs of concept" Sorry if that came off a bit snippy. I just couldn't resist the alliteration. > for HLL compilers targeting parrot. If y'all want to consider imcc > as just another member of that class, fine! But if we tell compiler > writers "You should target imcc, not parrot directly", then imcc > is clearly in a class by itself. I'm not sure this is what we're trying to say. The message is basically "every compiler needs to do this, and we have it implemented here". If it's useful, IMCC will live and grow. If not, it will end up being assimilated by the projects taht use it. > And no one has suggested that HLL compiler writers shoudl emit > befunge. Yet. :-) Forth, maybe. /s
