basicblock: handle athrow as return
[mate.git] / doc / TODO
1 (l) proper java native interface (JNI)
2         -> atm just hackish solution.
3         -> also, arguments are passed in the wrong order
4         -> estimated effort: 3-4 days
5
6 (l) exceptions
7         -> for gnu classpath absolutely necessary
8         -> estimated effort: unknown
9
10 (l) replace signals with "nice traps"?
11         pro -> don't rely on operating system anymore
12         pro -> maybe better ghci behaviour?
13         cons -> at some point, signals are useful for debugging?
14         cons -> better "template" tricks are needed, as we cannot insert more
15         instructions or want to place nop's at production code path
16
17 (l) gnu classpath integration
18         -> would be awwwesome
19         -> depends on: exceptions, jni (?)
20         -> estimated effort: unknown
21
22 (m) hoopl
23         -> for "frontEnd analysis"
24         -> transition to MIR (Mate IR)?
25
26 (h) switch statement (basically lookupswitch insn)
27
28 (m) testing: hunit? quickcheck? other?
29         -> we have `make tests' now, but it should be only considered as
30            high-level test. we need something
31         -> estimated effort: for infrastructure, 2-3 days
32
33 (l) instanceof, checkcast
34         -> typechecking at runtime. with displays or something
35         -> depends on: exceptions (not absolutely necessary, but preferable)
36         -> estimated effort: 1 day
37
38 (h) bug (?): can there be a namespace clash with static and non-static methods?
39         -> the signature doesn't contain the static modifier
40         -> estimated effort: some hours (if a fix is needed)
41
42 (h) global map hack:
43         -> it's an stupid and ugly hack. we don't want that.
44         -> estimated effort: unknown. research for a solution is needed
45
46 (l) cabal file
47
48 (h) so much cleanup...
49         -> define constant for native size stuff
50         -> and much more
51
52 (m) enable easy recompiliation of a method
53         -> we need a map where all callers are stored
54            in order to patch those to the new address
55         -> free old code region. maybe replace it with
56            some magic values, e.g. which produce a signal
57            in order to enable easier debugging
58
59 (h) get rid of trap.c
60         -> it's C. we don't want that.
61         -> at the moment System.Posix.Signal isn't powerful enough
62         -> wait for: http://hackage.haskell.org/trac/ghc/ticket/2451
63
64 (l) check different types (byte, long, ...)
65
66 (l) floating point support
67
68 (h) better code generation
69         -> at least peephole optimazation would be nice (e.g. kill `push eax; pop
70         eax')
71         -> but we want more!!11 ;-)
72         -> estimated effort: 2-3 weeks
73
74 (m) benchmark for presentation
75
76 (l) get rid of missingh
77         -> huge dependency and we just need one function of it
78
79 (l) get more details what takes time
80         -> use Data.Time.Clock
81         -> seperate analysis, jit, execution, ...
82         -> maybe use ghc profiling? (it doesn't measure native execution, but well)
83
84 (l) testing
85         -> specjvm98
86         -> dacapo benchmark suite
87
88
89 (l) ... low priority
90 (m) ... medium priority
91 (h) ... high priority
92
93
94 what we won't do anytime soon:
95 ( ) garbage collection
96 ( ) thread support
97 ( ) verifier
98
99
100
101 /* old stuff */
102 Design Meeting - 21.March.2012
103
104
105 1) Compile on Basic Blocks on Demand or complete Methods (check how cacao, mono works)
106 2) Calling-Conventions - Standard wegen den Sprüngen (why does Cacao use strange CallingConventions)
107 3) Capture Meta-Information by Instruction and Basics-Block
108 4) Benchmark Suits - what features do we need?
109 5) Boehm GC? using Haskell GC? From Scratch GC? GC option
110 6) hs-java reinschauen - kann das schon BBA
111
112
113 TODO: Basic-Block Analyis, Dereferencing .class file shit - during or after BBA,