1 GMQCC is quite feature compleat. But that doesn't address the fact that
2 it can be improved. This is a list of things that we're like to support
3 in the distant future. When the time comes, we can just select a topic
4 from here and open a ticket for it on the issue tracker. But for the
5 meantime, this is sort of a cultivating flat file database.
8 The following are optimizations that can be implemented after the
9 transformation into static-single assignment (SSA).
11 Global Value Numbering:
12 Eliminate redundancy by constructing a value graph of the source
13 then determinging which values are computed by equivalent expressions.
14 Simaler to Common Subexpression Elimination (CSE), however expressions
15 are determined via underlying equivalnce, opposed to lexically identical
18 Spare Conditional Constant Propogation:
19 Simultaneously remove dead code and propogates constants. This is
20 not the same as indivial dead code elimination and constant propogation
21 passes. This is multipass.
23 The following are optimizations that can be implemented before the
24 transformation into a binary (code generator).
27 The process of finding sequences of code that are identical,
28 or can be parameterized or reordered to be identical.
29 Which can be replaced with calls to a shared subroutine. To
30 reduce duplicated code. (Size optimization)
32 The following are optimizations that can be implemented anywhere, ideally
33 these are functional language optimizations.
36 Tail recrusive algorithms can be converted to iteration, which
37 does not have to have call overhead.
41 The following are language features that we'd like to see implemented in the
48 Macros with sanity. Not textual subsitution.
51 Like C++, but minus the stupidity:
52 - No type operator overloads
53 - Keep operator overloading for basic operators though.
56 They're currently implemented, but support in the engine
57 plus implicit bounds checks (and ability to turn the bounds
61 I feel like all languages suck at implementing this. This would
62 require support from the engine, but it would help catch bugs. We
63 could make it fast using a neat method of "frame pointers".
66 Ability to make individual functions with the same nume, but take
67 different amount of arguments or type of arguments.
69 Default Argument Subsitution:
70 Ability to specify default values for arguments in functions.
71 void foo(string bar, string baz="default");
72 Supplying just one argument will expand the second argument to
73 become "default", otherwise if two arguments are specified then
74 the "default" string is overrode with what ever the user passes.
77 A char type would be nice to have. Essentially implemented as a
78 string, we can both "get" and "set" indices inside strings with
79 the help of builtin functions.
85 print("it's time to ", foo);
88 Array Accessor With C-Semantics:
89 Also the abilit to use them as array accessors:
94 hugearray['a'] = 100.0f;
97 Keep existing "pointer-like" semantics as well. In C arrays
98 simple work as pointers, a[1] -> *(a+1), or 1[a] -> *(1+a)
99 so we should allow both forms of syntax. As well as operand
108 FTEQCC Inline Assembly:
109 This is still up for debate, mainly because a) it's syntax is
110 just utter crap. b) If we do an assembler, it should be nice.
111 we could provide a -std=fteqcc for the assembler itself :P
112 just like the compiler; although I think that's just insane.
114 Please see Assembler below.
117 There is already a ticket open on this. They'd work just like C++
121 The following are QCVM additions:
123 Proper ASM dissasembly:
124 Proper dissasembly of compiled .dat files. Annotated if possible
125 when -g (is used during compilation)
128 A step-through debuger -d (with seperate compilation as well)
129 Called -> qcdb Optionally alias to qcvm -d :)
131 We should beable to see the assembly and source it matches to
132 and the state of OFS_* and calls.
135 The followiung are things we'd like to see added to the testsuite
136 in the distant future:
139 Chances are when we start adding more and more tests, executing
140 them individually will be midly slow (even if that's a whole minute)
141 It would be nice to add a -j paramater to allow multiple threads to
142 be used and so we can execute many tests in parallel.
145 Ability to select individual tests, or set paramaters manually
146 opposed to using the static task-template files. (A method to
147 override them rather).
151 Possibly support for a future assembler for QCASM. But we're not
152 entierly sure if it makes sense.