On Sat, Feb 22, 2003 at 12:31:09PM +0100, Leopold Toetsch wrote: > Nicholas Clark wrote: > > >On Fri, Feb 21, 2003 at 08:34:05AM +0100, Leopold Toetsch wrote: > > >>Case 2) should disable only core_ops_cg.c but not core_ops_cgp.c > >> > > > >But surely we'd also like a flag to disable core_ops_cgp.c but leave > >core_ops_cg.c? > > > IMHO no. Why disable the faster and much smaller core, and keep the big > and slow core?
It might just be that on someone's machine the faster and smaller core triggers a compiler bug. And > Here is a summary in terms of speed: > JIT > CGP (obsoletes CGoto & Prederef) > Switched Prederef (obsoletes Prederef) > Switched > Normal > > When PBC code size matters we could have: > CGoto you've already found a reason why someone might want the "obsoleted" CGoto core. I'm not saying that we recommend using, or even default to building any obsolete cores that we ship source for. Merely that we ensure that the configure system is flexible enough to let anyone build any arbitrary combination of cores they ask for. (Providing they answer yes enough times to "do you really want to do that?"). It strikes me that having rules in the configure system to explicitly forbid compiling certain combinations of cores is actually more complex than not having such rules. I forget who I'm misquoting, but good tools can be used in ways their makers never even thought of. Nicholas Clark
