f65d294d46cf90aa4fc9fd664c3307602d2845db
[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
85 (l) ... low priority
86 (m) ... medium priority
87 (h) ... high priority
88
89
90 what we won't do anytime soon:
91 ( ) garbage collection
92 ( ) thread support
93 ( ) verifier
94
95
96
97 /* old stuff */
98 Design Meeting - 21.March.2012
99
100
101 1) Compile on Basic Blocks on Demand or complete Methods (check how cacao, mono works)
102 2) Calling-Conventions - Standard wegen den Sprüngen (why does Cacao use strange CallingConventions)
103 3) Capture Meta-Information by Instruction and Basics-Block
104 4) Benchmark Suits - what features do we need?
105 5) Boehm GC? using Haskell GC? From Scratch GC? GC option
106 6) hs-java reinschauen - kann das schon BBA
107
108
109 TODO: Basic-Block Analyis, Dereferencing .class file shit - during or after BBA,