izaya
/
collapseos
mirror of https://github.com/hsoft/collapseos.git
1
0
Fork 0
Code Issues Releases Wiki Activity
collapseos/tools/tests/unit/test_expr.asm

156 lines
2.3 KiB
NASM
Raw Normal View History

zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
.equ RAMSTART 0x4000
recipes/sms/romasm: make zasm's memory usage fit the SMS
2019-07-24 06:50:19 +10:00
.equ ZASM_REG_MAXCNT 0xff
.equ ZASM_LREG_MAXCNT 0x40
.equ ZASM_REG_BUFSZ 0x1000
.equ ZASM_LREG_BUFSZ 0x200
zasm: add "last value" symbol (@)
2019-10-05 10:26:21 +10:00
; declare DIREC_LASTVAL manually so that we don't have to include directive.asm
.equ DIREC_LASTVAL RAMSTART
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
jp test
test: begin adding common test harnessing code This should make tests a bit more convenient to write and debug. Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a parseExpr implemented using a recursive descent algo, it passes all tests, but it unfortunately assembles a faulty zasm. I have to find the expressions that it doesn't parse properly. But before I do that, I prefer to commit these significant improvements I've been making to tests harness in parallel of this development.
2019-12-24 07:41:25 +11:00
.inc "ascii.h"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-07 05:32:23 +11:00
.inc "core.asm"
Extract str.asm from core.asm and make core included by userspace Most of register fiddling routines (which is now the only thing contained in care.asm) are used by almost all userspace apps, often in inner loops. That makes the penalty of using jump tables for those a bit too high. Moreover, it burdens jump tables needlessly. Because this unit is very small (now that string routines are out), it makes sense to always include it in binaries.
2019-11-15 01:55:31 +11:00
.inc "str.asm"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-07 05:32:23 +11:00
.inc "lib/util.asm"
lib/expr: refactor for easier operator addition
2019-11-23 06:45:12 +11:00
.inc "lib/ari.asm"
test: begin adding common test harnessing code This should make tests a bit more convenient to write and debug. Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a parseExpr implemented using a recursive descent algo, it passes all tests, but it unfortunately assembles a faulty zasm. I have to find the expressions that it doesn't parse properly. But before I do that, I prefer to commit these significant improvements I've been making to tests harness in parallel of this development.
2019-12-24 07:41:25 +11:00
.inc "lib/fmt.asm"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-07 05:32:23 +11:00
.inc "zasm/util.asm"
.inc "zasm/const.asm"
.inc "lib/parse.asm"
.inc "zasm/parse.asm"
zasm: add "last value" symbol (@)
2019-10-05 10:26:21 +10:00
.equ SYM_RAMSTART DIREC_LASTVAL+2
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-07 05:32:23 +11:00
.inc "zasm/symbol.asm"
basic: add expression support to print Again, same thing as in zasm.
2019-11-19 07:52:07 +11:00
.equ EXPR_PARSE parseNumberOrSymbol
.inc "lib/expr.asm"
test: begin adding common test harnessing code This should make tests a bit more convenient to write and debug. Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a parseExpr implemented using a recursive descent algo, it passes all tests, but it unfortunately assembles a faulty zasm. I have to find the expressions that it doesn't parse properly. But before I do that, I prefer to commit these significant improvements I've been making to tests harness in parallel of this development.
2019-12-24 07:41:25 +11:00
.equ STDIO_RAMSTART SYM_RAMEND
.inc "stdio.asm"
.inc "common.asm"
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
; Pretend that we aren't in first pass
zasmIsFirstPass:
jp unsetZ
zasm: add support for "$" symbol Allows for the ".fill x-$" pattern.
2019-05-20 23:17:50 +10:00
zasmGetPC:
ret
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
sFOO: .db "FOO", 0
sBAR: .db "BAR", 0
test:
lib/expr: add division and modulo operators
2019-11-23 07:03:16 +11:00
ld sp, 0xffff
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
test_expr: simplify
2019-12-30 07:39:39 +11:00
; before testing begins, let's set up FOO and BAR symbols
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
call symInit
ld hl, sFOO
ld de, 0x4000
zasm: remove SYM_CTX
2019-07-23 05:59:47 +10:00
call symRegisterGlobal
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
jp nz, fail
ld hl, sBAR
ld de, 0x20
zasm: remove SYM_CTX
2019-07-23 05:59:47 +10:00
call symRegisterGlobal
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
jp nz, fail
test_expr: simplify
2019-12-30 07:39:39 +11:00
call testParseExpr
lib/expr: fix stack imbalance on failure
2019-12-30 08:15:48 +11:00
call testSPOnFail
zasm: fix expr operator priority
2019-05-19 05:17:56 +10:00
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-18 03:14:16 +10:00
; success
xor a
halt
lib/expr: add division and modulo operators
2019-11-23 07:03:16 +11:00
testParseExpr:
lib/expr: make recursion process a bit more orderly Instead of going left and right, finding operators chars and replacing them with nulls, we parse expressions in a more orderly manner, one chunk at a time. I think it qualifies as "recursive descent", but I'm not sure. This allows us to preserve the string we parse and should also make the implementation of parens much easier.
2019-12-30 03:42:18 +11:00
ld hl, .alltests
ld ix, .test
jp testList
lib/expr: add division and modulo operators
2019-11-23 07:03:16 +11:00
lib/expr: make recursion process a bit more orderly Instead of going left and right, finding operators chars and replacing them with nulls, we parse expressions in a more orderly manner, one chunk at a time. I think it qualifies as "recursive descent", but I'm not sure. This allows us to preserve the string we parse and should also make the implementation of parens much easier.
2019-12-30 03:42:18 +11:00
.test:
push hl \ pop iy
lib/expr: add division and modulo operators
2019-11-23 07:03:16 +11:00
inc hl \ inc hl
parseExprDE --> parseExpr
2019-12-24 11:13:44 +11:00
call parseExpr
test: begin adding common test harnessing code This should make tests a bit more convenient to write and debug. Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a parseExpr implemented using a recursive descent algo, it passes all tests, but it unfortunately assembles a faulty zasm. I have to find the expressions that it doesn't parse properly. But before I do that, I prefer to commit these significant improvements I've been making to tests harness in parallel of this development.
2019-12-24 07:41:25 +11:00
call assertZ
ld l, (iy)
ld h, (iy+1)
lib/expr: make recursion process a bit more orderly Instead of going left and right, finding operators chars and replacing them with nulls, we parse expressions in a more orderly manner, one chunk at a time. I think it qualifies as "recursive descent", but I'm not sure. This allows us to preserve the string we parse and should also make the implementation of parens much easier.
2019-12-30 03:42:18 +11:00
jp assertEQW
lib/expr: add division and modulo operators
2019-11-23 07:03:16 +11:00
.t1:
.dw 7
.db "42/6", 0
.t2:
.dw 1
.db "7%3", 0
lib/expr: add bitwise operators
2019-11-23 09:16:51 +11:00
.t3:
.dw 0x0907
.db "0x99f7&0x0f0f", 0
.t4:
.dw 0x9fff
.db "0x99f7|0x0f0f", 0
.t5:
.dw 0x96f8
.db "0x99f7^0x0f0f", 0
lib/expr: add left/right shifting operators
2019-11-23 10:35:10 +11:00
.t6:
.dw 0x133e
.db "0x99f7}3", 0
.t7:
.dw 0xcfb8
.db "0x99f7{3", 0
basic: add support for signed integers
2019-11-24 06:56:23 +11:00
.t8:
.dw 0xffff
.db "-1", 0
test: begin adding common test harnessing code This should make tests a bit more convenient to write and debug. Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a parseExpr implemented using a recursive descent algo, it passes all tests, but it unfortunately assembles a faulty zasm. I have to find the expressions that it doesn't parse properly. But before I do that, I prefer to commit these significant improvements I've been making to tests harness in parallel of this development.
2019-12-24 07:41:25 +11:00
.t9:
.dw 10
.db "2*3+4", 0
lib/expr: make recursion process a bit more orderly Instead of going left and right, finding operators chars and replacing them with nulls, we parse expressions in a more orderly manner, one chunk at a time. I think it qualifies as "recursive descent", but I'm not sure. This allows us to preserve the string we parse and should also make the implementation of parens much easier.
2019-12-30 03:42:18 +11:00
; There was this untested regression during the replacement of find-and-subst
; parseExpr to the recursive descent one. It was time consuming to find. Here
; it goes, here it stays.
.t10:
.dw '-'+1
.db "'-'+1", 0
test_expr: simplify
2019-12-30 07:39:39 +11:00
.t11:
.dw 0x4023
.db "0x4001+0x22", 0
.t12:
.dw 0x4020
.db "FOO+BAR", 0
.t13:
.dw 0x60
.db "BAR*3", 0
.t14:
.dw 0x3ffd
.db "FOO-3", 0
.t15:
.dw 0x4080
.db "FOO+BAR*4", 0
lib/expr: make EXPR_PARSE "tail" HL Things are now much simpler.
2019-12-31 11:24:53 +11:00
; "0" is a special case, let's test it
.t16:
.dw 0
.db "0", 0
; Another one that caused troubles
.t17:
.dw 123
.db "0+123", 0
lib/expr: make recursion process a bit more orderly Instead of going left and right, finding operators chars and replacing them with nulls, we parse expressions in a more orderly manner, one chunk at a time. I think it qualifies as "recursive descent", but I'm not sure. This allows us to preserve the string we parse and should also make the implementation of parens much easier.
2019-12-30 03:42:18 +11:00
.alltests:
test_expr: simplify
2019-12-30 07:39:39 +11:00
.dw .t1, .t2, .t3, .t4, .t5, .t6, .t7, .t8, .t9, .t10, .t11, .t12
lib/expr: make EXPR_PARSE "tail" HL Things are now much simpler.
2019-12-31 11:24:53 +11:00
.dw .t13, .t14, .t15, .t16, .t17, 0
lib/expr: fix stack imbalance on failure
2019-12-30 08:15:48 +11:00
; Ensure that stack is balanced on failure
testSPOnFail:
ld (testSP), sp
ld hl, .sFail
call parseExpr
call assertNZ
call assertSP
jp nexttest
.sFail: .db "1+abc123", 0