From 47c53fa60aea198296a6d73974905c3fd203dff8 Mon Sep 17 00:00:00 2001 From: Irmen de Jong Date: Sat, 23 Apr 2022 20:44:59 +0200 Subject: [PATCH] todo --- docs/source/todo.rst | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/source/todo.rst b/docs/source/todo.rst index 785d646dd..2dfafd8d8 100644 --- a/docs/source/todo.rst +++ b/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)