From 49e7f6d31d0eb6e925ca7cc3a894fa2ba9bc228b Mon Sep 17 00:00:00 2001 From: Dale Weiler Date: Sun, 16 Dec 2012 22:48:46 +0000 Subject: [PATCH] Add TODO --- TODO | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 TODO diff --git a/TODO b/TODO new file mode 100644 index 0000000..76f627a --- /dev/null +++ b/TODO @@ -0,0 +1,154 @@ +GMQCC is quite feature compleat. But that doesn't address the fact that +it can be improved. This is a list of things that we're like to support +in the distant future. When the time comes, we can just select a topic +from here and open a ticket for it on the issue tracker. But for the +meantime, this is sort of a cultivating flat file database. + +Optimizations: + The following are optimizations that can be implemented after the + transformation into static-single assignment (SSA). + + Global Value Numbering: + Eliminate redundancy by constructing a value graph of the source + then determinging which values are computed by equivalent expressions. + Simaler to Common Subexpression Elimination (CSE), however expressions + are determined via underlying equivalnce, opposed to lexically identical + expressions (CSE). + + Spare Conditional Constant Propogation: + Simultaneously remove dead code and propogates constants. This is + not the same as indivial dead code elimination and constant propogation + passes. This is multipass. + + The following are optimizations that can be implemented before the + transformation into a binary (code generator). + + Code factoring: + The process of finding sequences of code that are identical, + or can be parameterized or reordered to be identical. + Which can be replaced with calls to a shared subroutine. To + reduce duplicated code. (Size optimization) + + The following are optimizations that can be implemented anywhere, ideally + these are functional language optimizations. + + Removing Recrusion: + Tail recrusive algorithms can be converted to iteration, which + does not have to have call overhead. + + +Language Features: + The following are language features that we'd like to see implemented in the + future. + + Enumerations: + Like C + + AST Macros: + Macros with sanity. Not textual subsitution. + + Classes: + Like C++, but minus the stupidity: + - No type operator overloads + - Keep operator overloading for basic operators though. + + Arrays: + They're currently implemented, but support in the engine + plus implicit bounds checks (and ability to turn the bounds + checking off) See + + Exceptions: + I feel like all languages suck at implementing this. This would + require support from the engine, but it would help catch bugs. We + could make it fast using a neat method of "frame pointers". + + Overloaded Functions: + Ability to make individual functions with the same nume, but take + different amount of arguments or type of arguments. + + Default Argument Subsitution: + Ability to specify default values for arguments in functions. + void foo(string bar, string baz="default"); + Supplying just one argument will expand the second argument to + become "default", otherwise if two arguments are specified then + the "default" string is overrode with what ever the user passes. + + Character Type: + A char type would be nice to have. Essentially implemented as a + string, we can both "get" and "set" indices inside strings with + the help of builtin functions. + + { + string foo = "test"; + foo[0] = 'r'; + + print("it's time to ", foo); + } + + Array Accessor With C-Semantics: + Also the abilit to use them as array accessors: + + { + float hugearray['Z']; + + hugearray['a'] = 100.0f; + } + + Keep existing "pointer-like" semantics as well. In C arrays + simple work as pointers, a[1] -> *(a+1), or 1[a] -> *(1+a) + so we should allow both forms of syntax. As well as operand + reversal. + + { + float h['Z']; + *(h+'a') = 100; + *('a'+h) = 'a'[h]; + } + + FTEQCC Inline Assembly: + This is still up for debate, mainly because a) it's syntax is + just utter crap. b) If we do an assembler, it should be nice. + we could provide a -std=fteqcc for the assembler itself :P + just like the compiler; although I think that's just insane. + + Please see Assembler below. + + Namespaces: + There is already a ticket open on this. They'd work just like C++ + identically even. + +Standalone QCVM: + The following are QCVM additions: + + Proper ASM dissasembly: + Proper dissasembly of compiled .dat files. Annotated if possible + when -g (is used during compilation) + + Debugging: + A step-through debuger -d (with seperate compilation as well) + Called -> qcdb Optionally alias to qcvm -d :) + + We should beable to see the assembly and source it matches to + and the state of OFS_* and calls. + +Testsuite: + The followiung are things we'd like to see added to the testsuite + in the distant future: + + Multithreading: + Chances are when we start adding more and more tests, executing + them individually will be midly slow (even if that's a whole minute) + It would be nice to add a -j paramater to allow multiple threads to + be used and so we can execute many tests in parallel. + + Interface: + Ability to select individual tests, or set paramaters manually + opposed to using the static task-template files. (A method to + override them rather). + + +Assembler: + Possibly support for a future assembler for QCASM. But we're not + entierly sure if it makes sense. + + -- 2.39.2