izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
213614af33
collapseos/tools/tests/unit/test_expr.asm

162 lines
2.4 KiB
NASM
Raw Normal View History

zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
.equ RAMSTART 0x4000
recipes/sms/romasm: make zasm's memory usage fit the SMS
2019-07-23 16:50:19 -04: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-04 20:26:21 -04: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-17 13:14:16 -04: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-23 15:41:25 -05:00
.inc "ascii.h"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-06 14:32:23 -04: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-14 09:55:31 -05:00
.inc "str.asm"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-06 14:32:23 -04:00
.inc "lib/util.asm"
lib/expr: refactor for easier operator addition
2019-11-22 14:45:12 -05: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-23 15:41:25 -05:00
.inc "lib/fmt.asm"
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-06 14:32:23 -04:00
.inc "zasm/util.asm"
.inc "zasm/const.asm"
.inc "lib/parse.asm"
.inc "zasm/parse.asm"
zasm: add "last value" symbol (@)
2019-10-04 20:26:21 -04:00
.equ SYM_RAMSTART DIREC_LASTVAL+2
zasm: rename #inc to .inc scas, it's not needed any more.
2019-10-06 14:32:23 -04:00
.inc "zasm/symbol.asm"
basic: add expression support to print Again, same thing as in zasm.
2019-11-18 15:52:07 -05: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-23 15:41:25 -05: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-17 13:14:16 -04: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 09:17:50 -04:00
zasmGetPC:
ret
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
s1: .db "2+2", 0
s2: .db "0x4001+0x22", 0
s3: .db "FOO+BAR", 0
zasm: fix expr operator priority
2019-05-18 15:17:56 -04:00
s4: .db "BAR*3", 0
zasm: fix false truncation error on "-" expressions
2019-05-18 14:51:11 -04:00
s5: .db "FOO-3", 0
zasm: fix expr operator priority
2019-05-18 15:17:56 -04:00
s6: .db "FOO+BAR*4", 0
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
sFOO: .db "FOO", 0
sBAR: .db "BAR", 0
test:
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05:00
ld sp, 0xffff
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
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-23 15:41:25 -05:00
; New-style tests
lib/expr: fix unary minus For some reason, I've mistakenly disabled tests in test_expr without noticing and I also broke "-123" parsing. Fixed.
2019-12-23 20:53:31 -05:00
call testParseExpr
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-23 15:41:25 -05:00
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05:00
; Old-style tests, not touching them now.
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
ld hl, s1
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 4
call assertEQW
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
call nexttest
ld hl, s2
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 0x4023
call assertEQW
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
call nexttest
; before the next test, let's set up FOO and BAR symbols
call symInit
ld hl, sFOO
ld de, 0x4000
zasm: remove SYM_CTX
2019-07-22 15:59:47 -04:00
call symRegisterGlobal
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
jp nz, fail
ld hl, sBAR
ld de, 0x20
zasm: remove SYM_CTX
2019-07-22 15:59:47 -04:00
call symRegisterGlobal
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
jp nz, fail
ld hl, s3
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 0x4020
call assertEQW
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
call nexttest
zasm: add multiplication expressions
2019-05-17 22:22:10 -04:00
ld hl, s4
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 0x60
call assertEQW
zasm: add multiplication expressions
2019-05-17 22:22:10 -04:00
call nexttest
zasm: fix false truncation error on "-" expressions
2019-05-18 14:51:11 -04:00
ld hl, s5
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 0x3ffd
call assertEQW
zasm: fix false truncation error on "-" expressions
2019-05-18 14:51:11 -04:00
call nexttest
zasm: fix expr operator priority
2019-05-18 15:17:56 -04:00
ld hl, s6
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05:00
call assertZ
ld hl, 0x4080
call assertEQW
zasm: fix expr operator priority
2019-05-18 15:17:56 -04:00
call nexttest
zasm: don't match prefixes in symFind Only match when full names match.
2019-05-17 13:14:16 -04:00
; success
xor a
halt
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05: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-29 11:42:18 -05:00
ld hl, .alltests
ld ix, .test
jp testList
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05: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-29 11:42:18 -05:00
.test:
push hl \ pop iy
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05:00
inc hl \ inc hl
parseExprDE --> parseExpr
2019-12-23 19:13:44 -05: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-23 15:41:25 -05: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-29 11:42:18 -05:00
jp assertEQW
lib/expr: add division and modulo operators
2019-11-22 15:03:16 -05:00
.t1:
.dw 7
.db "42/6", 0
.t2:
.dw 1
.db "7%3", 0
lib/expr: add bitwise operators
2019-11-22 17:16:51 -05: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-22 18:35:10 -05:00
.t6:
.dw 0x133e
.db "0x99f7}3", 0
.t7:
.dw 0xcfb8
.db "0x99f7{3", 0
basic: add support for signed integers
2019-11-23 14:56:23 -05: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-23 15:41:25 -05: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-29 11:42:18 -05: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
.alltests:
.dw .t1, .t2, .t3, .t4, .t5, .t6, .t7, .t8, .t9, .t10, 0
Reference in New Issue Copy Permalink