-> 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)
+
+(h) patching also possible with harpy?
+ -> we can use a own buffer @ codegeneration...
+
(l) ... low priority
(m) ... medium priority
projects / mate.git / blobdiff