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?
How many cores are there now? Is there a way to make a modular flag system that lets people configure any arbitrary combination that they wish to build?
In the long run, we should build the "normal" function based core (used e.g. for trace and the fastest core, that is available. Though I can imagine, that we additionally want to have the most memory efficient core too - which would not be a prederefed one.
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 Switched Normal
So, the plain prederefed core is always obsolete now.
And an easy way for the tinderbox machines to build all applicable, and run tests for each built core in turn?
$ make quickfulltest
Nicholas Clark
leo