fix register clobber on @()

This commit is contained in:
Irmen de Jong 2025-01-05 14:32:39 +01:00
parent 420793f9e2
commit 3b5cda85ff
2 changed files with 1 additions and 4 deletions

View File

@ -98,7 +98,7 @@ sealed class PtExpression(val type: DataType, position: Position) : PtNode(posit
is PtFunctionCall -> false is PtFunctionCall -> false
is PtIdentifier -> true is PtIdentifier -> true
is PtIrRegister -> true is PtIrRegister -> true
is PtMemoryByte -> address is PtNumber || address is PtIdentifier is PtMemoryByte -> address is PtNumber
is PtBool -> true is PtBool -> true
is PtNumber -> true is PtNumber -> true
is PtPrefix -> value.isSimple() is PtPrefix -> value.isSimple()

View File

@ -81,9 +81,6 @@ Libraries
Optimizations Optimizations
------------- -------------
- if magicwall_enabled and (jiffy_counter & 3 == 1) sounds.magicwall() -> generates shortcut jump to another jump, why not immediately after the if
- if cx16.r0L>=97 and cx16.r0L<=122 {...} -> treats the boolean condition as a byte 0/1 result , can't it somehow just act on the carry bit alone?
same with if x1!=x2 or y1!=y2..... but it's because of the way boolean expressions are handled... can this be optimized?
- Optimize the IfExpression code generation to be more like regular if-else code. (both 6502 and IR) search for "TODO don't store condition as expression" - Optimize the IfExpression code generation to be more like regular if-else code. (both 6502 and IR) search for "TODO don't store condition as expression"
- VariableAllocator: can we think of a smarter strategy for allocating variables into zeropage, rather than first-come-first-served? - VariableAllocator: can we think of a smarter strategy for allocating variables into zeropage, rather than first-come-first-served?
for instance, vars used inside loops first, then loopvars, then uwords used as pointers (or these first??), then the rest for instance, vars used inside loops first, then loopvars, then uwords used as pointers (or these first??), then the rest