todo

docs/source/todo.rst

@@ -3,8 +3,8 @@ TODO
 
 For next release
 ^^^^^^^^^^^^^^^^
+- vm: implement floating point
 - pipe operator: allow non-unary function calls in the pipe that specify the other argument(s) in the calls.
-- createAssemblyAndAssemble(): make it possible to actually get rid of the VarDecl nodes by fixing the rest of the code mentioned there.
 - allow "xxx" * constexpr  (where constexpr is not a number literal), now gives expression error not same type
 - make it possible to inline non-asmsub routines that just contain a single statement (return, functioncall, assignment)
   but this requires all identifiers in the inlined expression to be changed to fully scoped names.
@@ -26,8 +26,7 @@ Future Things and Ideas
 ^^^^^^^^^^^^^^^^^^^^^^^
 Compiler:
 
-- vm: codegen: various TODOs to tweak code
-- vm: expressionGen: various TODOs to tweak code
+- vm: codeGen: various TODOs to tweak code
 - vm: make registers typed? so that it's immediately obvious what type they represent. Much like regular variables in memory.
   so we have a set of byte registers, a set of word registers, and other sets if we introduce other types.
 - vm: don't store symbol names in instructions to make optimizing the IR easier? but what about jumps to labels. And it's no longer readable by humans.
@@ -38,13 +37,15 @@ Compiler:
   So the CodeGen doesn't do VariableAlloc *before* the codegen, but as a last step.
 - vm code gen: don't reuse registers and don't pre allocate variables? (except strings + arrays) but instead put them into registers too
     then we ALMOST have Static Single Assignment form in the VM code.  But what can we use that for?
+- createAssemblyAndAssemble(): make it possible to actually get rid of the VarDecl nodes by fixing the rest of the code mentioned there.
+  but probably better to rewrite the 6502 codegen on top of the new Ast.
 - make everything an expression? (get rid of Statements. Statements are expressions with void return types?).
 - simplifyConditionalExpression() should not split expression if it still results in stack-based evaluation, but how does it know?
-- simplifyConditionalExpression() sometimes introduces needless assignment to r9 tempvar (scenario sought)
+- simplifyConditionalExpression() sometimes introduces needless assignment to r9 tempvar (what scenarios?)
 - consider adding McCarthy evaluation to shortcircuit and/or expressions. First do ifs by splitting them up? Then do expressions that compute a value?
 - make it possible to use cpu opcodes such as 'nop' as variable names by prefixing all asm vars with something such as ``p8v_``? Or not worth it (most 3 letter opcodes as variables are nonsensical anyway)
   then we can get rid of the instruction lists in the machinedefinitions as well?
-- [problematic due to 64tass:] add a compiler option to not remove unused subroutines. this allows for building library programs. But this won't work with 64tass's .proc ...
+- [problematic due to using 64tass:] add a compiler option to not remove unused subroutines. this allows for building library programs. But this won't work with 64tass's .proc ...
   Perhaps replace all uses of .proc/.pend by .block/.bend will fix that?
   (but we lose the optimizing aspect of the assembler where it strips out unused code.
   There's not really a dynamic switch possible as all assembly lib code is static and uses one or the other)
@@ -60,12 +61,13 @@ Libraries:
 - add modes 2 and 3 to gfx2 (lowres 4 color and 16 color)?
 - add a flood fill routine to gfx2?
 - add a diskio.f_seek() routine for the Cx16 that uses its seek dos api? (only if that's stable)
+- use cx16 MACPTR() to load stuff faster?
 
 Expressions:
 
 - rethink the whole "isAugmentable" business.  Because the way this is determined, should always also be exactly mirrorred in the AugmentableAssignmentAsmGen or you'll get a crash at code gen time.
 - can we get rid of pieces of asmgen.AssignmentAsmGen by just reusing the AugmentableAssignment ? generated code should not suffer
-- rewrite expression tree evaluation such that it doesn't use an eval stack but flatten the tree into linear code that uses a fixed number of predetermined value 'variables'?
+- rewrite expression tree evaluation suchthat it doesn't use an eval stack but flatten the tree into linear code that uses a fixed number of predetermined value 'variables'?
   "Three address code" was mentioned.  https://en.wikipedia.org/wiki/Three-address_code
   these variables have to be unique for each subroutine because they could otherwise be interfered with from irq routines etc.
 - this removes the need for the BinExprSplitter? (which is problematic and very limited now)