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?


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





Reply via email to