invokevirtual: implement lazy class loading right
[mate.git] / doc / TODO
index 09a0175239db5f4af6c697bbd492f8d1ffdcf1ae..15f7cb7190f159e260aeaf7eeb246e1308306413 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,3 +1,103 @@
+(l) proper java native interface (JNI)
+       -> atm just hackish solution.
+       -> also, arguments are passed in the wrong order
+       -> estimated effort: 3-4 days
+
+(l) exceptions
+       -> 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
+       -> estimated effort: for infrastructure, 2-3 days
+
+(l) instanceof, checkcast
+       -> typechecking at runtime. with displays or something
+       -> depends on: exceptions (not absolutely necessary, but preferable)
+       -> estimated effort: 1 day
+
+(h) bug (?): can there be a namespace clash with static and non-static methods?
+       -> the signature doesn't contain the static modifier
+       -> estimated effort: some hours (if a fix is needed)
+
+(h) global map hack:
+       -> it's an stupid and ugly hack. we don't want that.
+       -> estimated effort: unknown. research for a solution is needed
+
+(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, ...)
+
+(l) floating point support
+
+(h) better code generation
+       -> at least peephole optimazation would be nice (e.g. kill `push eax; pop
+       eax')
+       -> but we want more!!11 ;-)
+       -> estimated effort: 2-3 weeks
+
+(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
+(h) ... high priority
+
+
+what we won't do anytime soon:
+( ) garbage collection
+( ) thread support
+( ) verifier
+
+
+
+/* old stuff */
 Design Meeting - 21.March.2012
 
 
@@ -10,5 +110,3 @@ Design Meeting - 21.March.2012
 
 
 TODO: Basic-Block Analyis, Dereferencing .class file shit - during or after BBA, 
-
-