Commit Graph

29 Commits

Author SHA1 Message Date
Virgil Dupras
b745f49186 Rename blockdev's API routines to GetB/PutB
The goal is to avoid mixing those routines with "character devices"
(acia, vpd, kbd) which aren't block devices and have routines that
have different expectations.

This is a first step to fixing #64.
2019-10-30 16:59:35 -04:00
Clanmaster21
38333e9e07 Decimal parse optimisations (#45)
* Optimised parsing functions and other minor optimisations

UnsetZ has been reduced by a byte, and between 17 and 28 cycles saved based on branching. Since branching is based on a being 0, it shouldn't have to branch very often and so be 28 cycles saved most the time. Including the initial call, the old version was 60 cycles, so this should be nearly twice as fast. 
fmtHex has been reduced by 4 bytes and between 3 and 8 cycles based on branching.
fmtHexPair had a redundant "and" removed, saving two bytes and seven cycles.
parseHex has been reduced by 7 bytes. Due to so much branching, it's hard to say if it's faster, but it should be since it's fewer operations and now conditional returns are used which are a cycle faster than conditional jumps. I think there's more to improve here, but I haven't come up with anything yet.

* Major parsing optimisations

Totally reworked both parseDecimal and parseDecimalDigit
parseDecimalDigit no longer exists, as it could be replaced by an inline alternative in the 4 places it appeared. This saves one byte overall, as the inline version is 4 bytes, 1 byte more than a call, and removing the function saved 5 bytes. It has been reduced from between 52 and 35 cycles (35 on error, so we'd expect 52 cycles to be more common unless someone's really bad at programming) to 14 cycles, so 2-3 times faster.
parseDecimal has been reduced by a byte, and now the main loop is just about twice as fast, but with increased overhead. To put this into perspective, if we ignore error cases:
For decimals of length 1 it'll be 1.20x faster, for decimals of length 2, 1.41x faster, for length 3, 1.51x faster, for length 4, 1.57x faster, and for length 5 and above, at least 1.48x faster (even faster if there's leading zeroes or not the worst case scenario).
I believe there is still room for improvement, since the first iteration can be nearly replaced with "ld l, c" since 0*10=0, but when I tried this I could either add a zero check into the main loop, adding around 40 cycles and 10 bytes, or add 20 bytes to the overhead, and I don't think either of those options are worth it.

* Inlined parseDecimalDigit

See previous commit, and /lib/parse.asm, for details

* Fixed tabs and spacing

* Fixed tabs and spacing

* Better explanation and layout

* Corrected error in comments, and a new parseHex

5 bytes saved in parseHex, again hard to say what that does to speed, the shortest possible speed is probably a little slower but I think non-error cases should be around 9 cycles faster for decimal and 18 cycles faster for hex as there's now only two conditional returns and no compliment carries.

* Fixed the new parseHex

I accidentally did `add 0xe9` without specifying `a`

* Commented the use of daa

I made the comments surrounding my use of daa much clearer, so it isn't quite so mystical what's being done here.

* Removed skip leading zeroes, added skip first multiply

Now instead of skipping leading zeroes, the first digit is loaded directly into hl without first multiplying by 10. This means the first loop is skipped in the overhead, making the method 2-3 times faster overall, and is now faster for the more common fewer digit cases too. The number of bytes is exactly the same, and the inner loop is slightly faster too thanks to no longer needing to load a into c.
To be more precise about the speed increase over the current code, for decimals of length 1 it'll be 3.18x faster, for decimals of length 2, 2.50x faster, for length 3, 2.31x faster, for length 4, 2.22x faster, and for length 5 and above, at least 2.03x faster. In terms of cycles, this is around 100+(132*length) cycles saved per decimal.

* Fixed erroring out for all number >0x1999

I fixed the errors for numbers >0x1999, sadly it is now 6 bytes bigger, so 5 bytes larger than the original, but the speed increases should still hold.

* Fixed more errors, clearer choice of constants

* Clearer choice of constants

* Moved and indented comment about fmtHex's method

* Marked inlined parseDecimalDigit uses

* Renamed .error, removed trailing whitespace, more verbose comments.
2019-10-24 07:58:32 -04:00
luz.paz
6a635fddd9 Fix misc. source comment typos
Found via `codespell -q 3 -S ./tools -L splitted`
2019-10-09 11:12:08 -04:00
Virgil Dupras
f4b6c7637d zasm: rename #inc to .inc
scas, it's not needed any more.
2019-10-06 14:32:23 -04:00
Virgil Dupras
8db1bdb245 ed: add '.' and '$' support 2019-10-04 13:49:33 -04:00
Virgil Dupras
c96c8e7df0 ed: update curline after a, i and d 2019-07-25 21:24:36 -04:00
Virgil Dupras
af0b6231ca recipes/sms/romasm: make ed's memory usage fit the SMS
Yup, that's ultimately why I've just made this whole big zasm
refactoring in the previous commits. To allow for this.

But also, zasm is in much better shape now...
2019-07-23 16:13:52 -04:00
Virgil Dupras
0237ff105f ed: fix 'd' going crazy when deleting last lines of buf 2019-07-21 19:43:45 -04:00
Virgil Dupras
0fd16a0bb6 ed: fix boken 'a' and 'd' cmds 2019-07-21 19:32:24 -04:00
Virgil Dupras
421d881fae ed: allow inserting in empty file 2019-07-21 15:06:03 -04:00
Virgil Dupras
01031a780a ed: Add 'w' command 2019-07-21 11:40:26 -04:00
Virgil Dupras
f6479486f2 ed: allow appending at the end of the file 2019-07-21 11:12:49 -04:00
Virgil Dupras
8d7abd9994 ed: fix broken buf insert logic 2019-07-21 10:53:11 -04:00
Virgil Dupras
1a5a1b9861 ed: make scratchpad memory only
The dual scraptchpad thing doesn't work. Things become very
complicated when it's time to write that back to the file. We
overwrite our contents and end up with garbage.
2019-07-21 10:45:58 -04:00
Virgil Dupras
942d2a952d ed: take filename as an argument
This hard-binds ed to the filesystem (I liked the idea of working
only with blockdevs though...), but this is necessary for the
upcoming `w` command. We need some kind of way to tell the
destination to write to truncate itself.

This only has a meaning in the filesystem, but it's necessary to
let the file know that its registered file size has possibly
shrunk.

I thought of alternatives that would have allowed me to keep ed
blkdev-centered, but they were all too hackish to my own taste.

Hence, this new hard-bind on files.
2019-07-20 19:43:07 -04:00
Virgil Dupras
eefadc3917 ed: add support for 'a' and 'i' 2019-07-14 17:35:21 -04:00
Virgil Dupras
77a23cee84 ed: fix bufDelLines logic
It was mostly wrong.
2019-07-14 16:18:33 -04:00
Virgil Dupras
5669884508 ed: read initial contents in bufInit 2019-07-14 12:19:37 -04:00
Virgil Dupras
3b0029335a ed: add README 2019-07-14 11:31:14 -04:00
Virgil Dupras
8af1cf468c ed: add 'd' cmd 2019-07-14 10:32:28 -04:00
Virgil Dupras
50d0dc982c ed: check addr bounds 2019-07-14 09:04:51 -04:00
Virgil Dupras
c811d5330c apps/ed: add support for addr ranges 2019-07-13 22:09:17 -04:00
Virgil Dupras
2d9f74c2af apps/ed: refactoring 2019-07-13 21:08:16 -04:00
Virgil Dupras
8cf68dc7ad apps/ed: handle +[n] and -[n] addresses 2019-07-13 16:30:30 -04:00
Virgil Dupras
951dd2206d apps/ed: add the concept of "current line" 2019-07-13 15:28:44 -04:00
Virgil Dupras
e0f2a71dfc apps/ed: print specified line 2019-07-13 14:01:20 -04:00
Virgil Dupras
6dbbfa837d apps/ed: add (dummy) line number processing
Starting to feel interactive...
2019-07-13 11:53:30 -04:00
Virgil Dupras
3491c26132 apps/ed: start implementing I/O 2019-07-13 11:29:06 -04:00
Virgil Dupras
3d474c9121 apps/ed: first steps 2019-07-13 09:57:37 -04:00