basicblock: handle athrow as return
[mate.git] / doc / TODO
index cef269182f7175088f6ab295166b11be7b18bf4e..525ed7c5e9927b4aac79be6ac95fa27e9ef3eea4 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -7,11 +7,24 @@
        -> for gnu classpath absolutely necessary
        -> estimated effort: unknown
 
+(l) replace signals with "nice traps"?
+       pro -> don't rely on operating system anymore
+       pro -> maybe better ghci behaviour?
+       cons -> at some point, signals are useful for debugging?
+       cons -> better "template" tricks are needed, as we cannot insert more
+       instructions or want to place nop's at production code path
+
 (l) gnu classpath integration
        -> would be awwwesome
        -> depends on: exceptions, jni (?)
        -> estimated effort: unknown
 
+(m) hoopl
+       -> for "frontEnd analysis"
+       -> transition to MIR (Mate IR)?
+
+(h) switch statement (basically lookupswitch insn)
+
 (m) testing: hunit? quickcheck? other?
        -> we have `make tests' now, but it should be only considered as
           high-level test. we need something
        -> it's an stupid and ugly hack. we don't want that.
        -> estimated effort: unknown. research for a solution is needed
 
-(m) hlint
-
 (l) cabal file
 
 (h) so much cleanup...
+       -> define constant for native size stuff
+       -> and much more
+
+(m) enable easy recompiliation of a method
+       -> we need a map where all callers are stored
+          in order to patch those to the new address
+       -> free old code region. maybe replace it with
+          some magic values, e.g. which produce a signal
+          in order to enable easier debugging
+
+(h) get rid of trap.c
+       -> it's C. we don't want that.
+       -> at the moment System.Posix.Signal isn't powerful enough
+       -> wait for: http://hackage.haskell.org/trac/ghc/ticket/2451
 
 (l) check different types (byte, long, ...)
 
 
 (m) benchmark for presentation
 
+(l) get rid of missingh
+       -> huge dependency and we just need one function of it
+
+(l) get more details what takes time
+       -> use Data.Time.Clock
+       -> seperate analysis, jit, execution, ...
+       -> maybe use ghc profiling? (it doesn't measure native execution, but well)
+
+(l) testing
+       -> specjvm98
+       -> dacapo benchmark suite
+
 
 (l) ... low priority
 (m) ... medium priority