-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
+GMQCC is quite feature complete. But that doesn't address the fact that
+it can be improved. This is a list of things that we'd 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.
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
+ then determining which values are computed by equivalent expressions.
+ Similar to Common Subexpression Elimination (CSE), however expressions
+ are determined via underlying equivalence, 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).
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.
+ Macros with sanity. Not textual substiution.
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".
+ - No inheritance
+ - No virtuals / pure virtuals
+ - Essentially "C structs but with operators" :)
Overloaded Functions:
- Ability to make individual functions with the same nume, but take
+ Ability to make individual functions with the same name, but take
different amount of arguments or type of arguments.
- Default Argument Subsitution:
+ Default Argument Substiution:
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
+ The following 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
+ Ability to select individual tests, or set parameters 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.
-
-
projects / xonotic / gmqcc.git / blobdiff