mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-14 13:23:53 +00:00
61a05131ac
Estimated hours taken: 8
Branches: main
Add an option `--no-inline-builtins', which causes builtins to
be generated as calls to out-of-line procedures. This is done
by default when debugging, as without this option the execution
of builtins is not traced.
On earth, a compiler built in grade asm_fast.gc.tr.debug
takes 36.8s to run `mmc -C -I ../analysis/ hlds.make_hlds'.
When the compiler is built with `--no-inline-builtins',
this is increased to 38.6s.
The size of the compiler built in grade asm_fast.gc.tr.debug
increases from 45.0MB to 46.6MB.
compiler/options.m:
Add the option.
compiler/code_util.m:
Work out whether builtins should be generated inline.
compiler/handle_options.m:
Disable inlining of builtins when debugging.
compiler/simplify.m:
compiler/higher_order.m:
compiler/modes.m:
code_util__builtin_state now needs to know where the
builtin is being called from to know whether a particular
call should be treated as an inline builtin. The "recursive"
calls from the automatically generated procedures for each
builtin should always be generated inline, or else we would
generate an infinite loop.
NEWS:
doc/user_guide.texi:
compiler/notes/todo.html:
Document the change.
tests/debugger/Mmakefile:
tests/debugger/no_inline_builtins.{m,exp,inp}:
Test case.
tests/debugger/*.{inp,exp,exp2}:
tests/debugger/declarative/*.{inp,exp,exp2}:
Update due to changed event numbers.
tests/debugger/lval_desc_array.inp:
Use a less brittle method for stepping to the point in
the program where the test needs to display variables.
tests/debugger/declarative/library_forwarding.m:
tests/debugger/declarative/*.m:
Add forwarding predicates for some library predicates
and functions so that the declarative debugger doesn't
ask different questions depending on whether or not
the library was compiled with debugging enabled.
423 lines
11 KiB
HTML
423 lines
11 KiB
HTML
<html>
|
|
<head>
|
|
<title>To Do List</title>
|
|
</head>
|
|
|
|
<body bgcolor="#ffffff" text="#000000">
|
|
|
|
<hr>
|
|
<!--======================-->
|
|
|
|
<h1> TODO LIST </h1>
|
|
|
|
<hr>
|
|
<!--======================-->
|
|
|
|
<p>
|
|
|
|
|
|
For more information on any of these issues, contact mercury@cs.mu.oz.au.
|
|
|
|
<p>
|
|
|
|
<h2> syntax </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> Warn about the use of the deprecated old-style lambda expressions.
|
|
|
|
</ul>
|
|
|
|
<h2> type system </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> Change type inference to handle ambiguity better
|
|
(see the XXX comment near the start of typecheck.m).
|
|
|
|
</ul>
|
|
|
|
<h2> mode analysis </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> fix various bugs in mode inference:
|
|
need to fix it to work properly in the presence of functions;
|
|
also need to change normalise_inst so that it handles complicated
|
|
insts such as `list_skel(any)'.
|
|
|
|
<li> extend the mode system to allow known aliasing.
|
|
This is needed to make partially instantiated modes and unique modes work.
|
|
[supported on the "alias" branch, but there were some serious
|
|
performance problems... has not been merged back into the main
|
|
branch]
|
|
|
|
<li> detect incorrect usage of `bound(...)' insts.
|
|
That is, make sure that all of the functors in a bound(...) inst
|
|
are valid functors for the type.
|
|
|
|
</ul>
|
|
|
|
<h2> determinism analysis </h2>
|
|
|
|
<p>
|
|
|
|
<ul>
|
|
<li> add functionality for promise exclusive declarations:
|
|
<ul>
|
|
<li> add error checking and type checking as for assertions
|
|
<li> include declaration information in the module_info
|
|
<li> take into account mutual exclusivity from promise_exclusive
|
|
and promise_exclusive_exhaustive declarations during switch
|
|
detection
|
|
<li> take into account exhaustiveness from promise_exhaustive and
|
|
promise_exclusive_exhaustive declarations during
|
|
determinism analysis
|
|
</ul>
|
|
</ul>
|
|
|
|
|
|
<h2> unique modes </h2>
|
|
|
|
<ul>
|
|
<li> handle nested unique modes
|
|
|
|
<li> we will probably need to extend unique modes a bit,
|
|
in as-yet-unknown ways; need more experience here
|
|
|
|
</ul>
|
|
|
|
<h2> module system </h2>
|
|
|
|
<ul>
|
|
<li> check that the interface for a module is type-correct
|
|
independently of any declarations or imports in the implementation
|
|
section
|
|
|
|
<li> there are some problems with nested modules (see the language
|
|
reference manual)
|
|
|
|
</ul>
|
|
|
|
<h2> C interface </h2>
|
|
|
|
<ul>
|
|
<li> exporting things for manipulating Mercury types from C
|
|
|
|
<li> better support for types defined in C
|
|
|
|
<li> need to deal with memory management issues
|
|
|
|
</ul>
|
|
|
|
<h2> code generation </h2>
|
|
|
|
<ul>
|
|
<li> take advantage of unique modes to do compile-time garbage collection
|
|
and structure reuse.
|
|
|
|
</ul>
|
|
|
|
<h2> back-ends </h2>
|
|
|
|
<h3> low-level (LLDS) back-end </h3>
|
|
<ul>
|
|
<li> support accurate garbage collection
|
|
</ul>
|
|
|
|
<h3> high-level C back-end </h3>
|
|
<ul>
|
|
<li> finish off support for accurate garbage collection;
|
|
see the comments in compiler/ml_elim_nested.m
|
|
<li> implement a better solution to the problem with abstract
|
|
equivalence types defined as float (the current solution
|
|
is to use --intermodule-optimization, but it would better
|
|
to only do this for abstract equivalence types)
|
|
<li> see also the comments in compiler/ml_code_gen.m
|
|
</ul>
|
|
|
|
<h2> native code back-end </h2>
|
|
<ul>
|
|
<li> support on platforms other than Linux/x86.
|
|
<li> commit GCC tail-call improvements to GCC CVS repository
|
|
<li> support `--gc accurate'
|
|
<li> support `--gc none'
|
|
</ul>
|
|
|
|
<h3> .NET back-end </h3>
|
|
<ul>
|
|
<li> finish off standard library implementation
|
|
<li> see also the TODO list in compiler/mlds_to_il.m
|
|
</ul>
|
|
|
|
<h3> Java back-end </h3>
|
|
<ul>
|
|
<li> implement the foreign language interface
|
|
<li> finish off standard library implementation
|
|
<li> see also the TODO list in compiler/mlds_to_java.m
|
|
</ul>
|
|
|
|
<h2> debugger </h2>
|
|
|
|
<ul>
|
|
<li> support back-ends other than LLDS
|
|
<li> allow interactive queries to refer to values generated by
|
|
the program being debugged
|
|
<li> conditional breakpoints
|
|
<li> trace semidet unifications
|
|
<li> graphical term browser
|
|
</ul>
|
|
|
|
<hr>
|
|
<!--======================-->
|
|
|
|
<h1> WISH LIST </h1>
|
|
|
|
<h2> type-system </h2>
|
|
|
|
<ul>
|
|
<li> allow explicit type qualifications `X : Type'
|
|
[already done, but need to change module qualifier op to `.' first]
|
|
|
|
<li> allow std_util:construct/4 to work for existential types
|
|
|
|
<li> remove limitation that higher-order terms are monomorphic.
|
|
i.e. allow universal quantifiers at the top level of
|
|
higher-order types, e.g. <samp>:- pred foo(all [T] pred(T)).</samp>.
|
|
|
|
<li> constructor classes
|
|
|
|
<li> allow a module exporting an abstract type to specify that other modules
|
|
should not be allowed to test two values of that type for equality (similar
|
|
to Ada's limited private types). This would be useful for e.g. sets
|
|
represented as unordered lists with possible duplicates.
|
|
[this is a subset of the functionality of type classes]
|
|
|
|
<li> subtypes?
|
|
|
|
<li> optimisation of type representation and manipulation (possibly
|
|
profiler guided)
|
|
|
|
<li> fold/unfolding of types
|
|
</ul>
|
|
|
|
<h2> mode analysis </h2>
|
|
|
|
<ul>
|
|
<li> split construct/deconstruct unifications into their atomic
|
|
"micro-unification" pieces when necessary.
|
|
(When is it necessary?)
|
|
|
|
<li> extend polymorphic modes,
|
|
e.g. to handle uniqueness polymorphism (some research issues?)
|
|
|
|
<li> handle abstract insts in the same way abstract types are handled
|
|
(a research issue - is this possible at all?)
|
|
|
|
<li> implement `willbe(Inst)' insts, for parallelism
|
|
|
|
<li> mode segments & high-level transformation of circularly moded programs.
|
|
</ul>
|
|
|
|
<h2> determinism analysis: </h2>
|
|
|
|
<ul>
|
|
<li> propagate information about bindings from the condition of an if-then-else
|
|
to the else so that
|
|
<pre>
|
|
(if X = [] then .... else X = [A|As], ...)
|
|
</pre>
|
|
is considered det.
|
|
|
|
<li> turn chains of if-then-elses into switchs where possible.
|
|
[done by fjh, but not committed; zs not convinced that
|
|
this is a good idea]
|
|
|
|
</ul>
|
|
|
|
<h2> higher-order preds: </h2>
|
|
|
|
<ul>
|
|
<li> implement single-use higher-order predicate modes.
|
|
Single-use higher-order predicates would be allowed to bind curried
|
|
arguments, and to have unique modes for curried arguments.
|
|
|
|
<li> allow taking the address of a predicate with multiple modes
|
|
|
|
<li> improve support for higher-order programming, eg. by providing
|
|
operators in the standard library which do things like:
|
|
<ul>
|
|
<li>compose functions
|
|
<li>take a predicate with one output argument and treat it like a function.
|
|
ie. <tt>:- func (pred(T)) = T.</tt>
|
|
</ul>
|
|
</ul>
|
|
|
|
<h2> module system: </h2>
|
|
|
|
<ul>
|
|
<li> produce warnings for implementation imports that are not needed
|
|
|
|
<li> produce warnings for imports that are in the wrong place
|
|
(in the interface instead of the implementation, and vice versa)
|
|
[vice versa done by stayl]
|
|
</ul>
|
|
|
|
<h2> source-level transformations </h2>
|
|
|
|
<ul>
|
|
<li> more work on module system, separate compilation, and the multiple
|
|
specialisation problem
|
|
|
|
<li> transform non-tail-recursive predicates into tail-recursive form
|
|
using accumulators. (This is already done, but not enabled by
|
|
default since it can make some programs run much more slowly.
|
|
More work is needed to only enable this optimization in cases
|
|
when it will improve performance rather than pessimize it.)
|
|
|
|
<li> improvements to deforestation / partial deduction
|
|
|
|
</ul>
|
|
|
|
<h2> code generation: </h2>
|
|
|
|
<ul>
|
|
<li> allow floating point fields of structures without boxing
|
|
(need multi-word fields)
|
|
|
|
<li> stack allocation of structures
|
|
|
|
<li> tail recursion optimization using pass-by-reference argument conventions
|
|
[being worked on by dmo]
|
|
|
|
</ul>
|
|
|
|
<h2> LLDS back-end: </h2>
|
|
|
|
<ul>
|
|
<li> use floating point registers
|
|
|
|
<li> inter-procedural register allocation
|
|
|
|
<li> other specializations, e.g. if argument is known to be bound to
|
|
f(X,Y), then just pass X and Y in registers
|
|
|
|
<li> reduce the overhead of higher-order predicate calls (avoid copying
|
|
the real registers into the fake_reg array and back)
|
|
|
|
<li> trim stack frames before making recursive calls, to minimize stack usage
|
|
(this would probably be a pessimization much of the time - zs)
|
|
and to minimize unnecessary garbage retention.
|
|
|
|
<li> target C--
|
|
</ul>
|
|
|
|
<h2> native code back-end </h2>
|
|
|
|
<ul>
|
|
<li> consider supporting exception handling in a manner
|
|
that is compatible with C++ and Java
|
|
<li> inline more of the standard library primitives that are
|
|
currently implemented in C
|
|
</ul>
|
|
|
|
<h2> garbage collection <h2>
|
|
<ul>
|
|
<li> implement liveness-accurate GC
|
|
<li> implement incremental GC
|
|
<li> implement generational GC
|
|
<li> implement parallel GC
|
|
<li> implement real-time GC
|
|
</ul>
|
|
|
|
<h2> compilation speed </h2>
|
|
|
|
<ul>
|
|
<li> improve efficiency of the expansion of equivalence types (currently O(N^2))
|
|
(e.g. this is particularly bad when compiling live_vars.m).
|
|
|
|
<li> improve efficiency of the module import handling (currently O(N^2))
|
|
|
|
<li> improve the efficiency of mode checking very large facts
|
|
(e.g. this is particularly bad when compiling eliza.m).
|
|
|
|
<li> use "store" rather than "map" for the major compiler data structures
|
|
</ul>
|
|
|
|
|
|
<h2> better diagnostics </h2>
|
|
|
|
<ul>
|
|
<li> optional warning for any implicit quantifiers whose scope is not
|
|
the entire clause (the "John Lloyd" option :-).
|
|
|
|
<li> give a better error message for the use of if-then without else.
|
|
|
|
<li> give a better error message for the use of `<=' instead of `=<'
|
|
(but how?)
|
|
|
|
<li> give a better error message for type errors involving higher-order pred
|
|
constants (requested by Bart Demoen)
|
|
|
|
<li> give better error messages for syntax errors in lambda expressions
|
|
</ul>
|
|
|
|
<h2> general </h2>
|
|
|
|
<ul>
|
|
<li> coroutining and parallel versions of Mercury
|
|
|
|
<li> implement streams (need coroutining at least)
|
|
|
|
<li> implement a very fast turn-around bytecode compiler/interpreter/debugger,
|
|
similar to Gofer
|
|
[not-so-fast bytecode compiler done, but bytecode interpreter
|
|
not implemented]
|
|
|
|
<li> implement user-defined operators: <br>
|
|
Add a new construct `:- op(Pred, Type, Op).' as in Prolog;
|
|
change prog_io.m to parse this construct and call io__op
|
|
accordingly. But how does this fit in with the module system?
|
|
|
|
<li> support for easier formal specification translation (eg a Z library,
|
|
or Z to Mercury).
|
|
|
|
<li> improve support for constraint programming
|
|
|
|
<li> implement a source visualisation tool
|
|
|
|
<li> distributed Mercury
|
|
|
|
<li> improved development environment
|
|
|
|
<li> additional software engineering tools
|
|
<ul>
|
|
<li> coverage analysis
|
|
<li> automatic testing
|
|
</ul>
|
|
|
|
<li> literate Mercury
|
|
|
|
<li> implement a GUI library (eg Hugs - Fudgets)
|
|
|
|
<li> profiling guided optimisations
|
|
<ul>
|
|
<li> use profiling information to direct linker for optimal
|
|
code placement (Alpha has a tool for this).
|
|
</ul>
|
|
|
|
<li> use of attribute grammar technology
|
|
(including visit sequence optimization)
|
|
to implement code with circular modes
|
|
</ul>
|
|
|
|
<hr>
|
|
<!--======================-->
|
|
|
|
Last update was $Date: 2003-01-30 05:59:23 $ by $Author: stayl $@cs.mu.oz.au. <br>
|
|
</body>
|
|
</html>
|