wAx: Wedge Assembler/Disassembler

[chysn]

PM sent - I guess ... sometimes the outbox gets stuck here, is that normal?

Got it, thanks!

I just reclaimed 43 bytes by moving the tool routing to an RTS-based address table. 43 bytes! That's a real bounty. I can add another pretty big feature. I could probably put the search back. But I'm thinking a move tool.

Edit: I removed Search for a reason, and I've never once really used the move/copy in VICmon. What I really needed was a hex-to-base10 converter. So, boom, done. https://youtu.be/7Hy_RcrXwvo

[chysn]

All right, this evening's optimization project involved inlining some subroutines, re-use of code snippets (like clc/rts), and changing subroutine endings of the form

Code: Select all

jsr Somewhere
rts

to

Code: Select all

jmp Somewhere

All this work garnered me enough bytes to add a save-to-disk tool. I removed the hex converter in exchange, which was really small, but I think the save was the most useful possible option. I could have had a less-flashy converter and a somewhat less friendly save tool, but they weren't compromises I was willing to make.

Sure, you can save a memory range with BASIC, but it's a lot of pain-in-the-ass typing, and I really needed to dig into those KERNAL routines at some point.

https://youtu.be/kdqou8TXDs0
https://github.com/Chysn/wAx/wiki/9-Memory-Save

[chysn]

Okay, okay, this is seriously the last feature that I'm probably going to be able to squeeze into 2048 bytes. What I've learned is that my first drafts are just super-inefficient, and I can gain vast swaths of memory by just staring at code.

The new feature is one that I particularly love, because trying to guess future relative branch addresses makes me pause and lose my mojo. This feature allows you to enter an * as an operand for a relative branch instruction with an unknown address, and then * in the future to resolve the original instruction's offset. Watch the video, it's really cool.

Code: Select all

; Assemble
@1200 BCC *
; A bunch of stuff
@1250 *
@1250 RTS

; Disassemble
$1200
@1200 BCC $1250

https://youtu.be/tPkia0p2MS8

[Mike]

What I've learned is that my first drafts are just super-inefficient, [...]

... or just straightforward, which is a good thing, IMO, if you want *working* code right from the beginning.

and I can gain vast swaths of memory by just staring at code.

Though 65xx code has the tendency to 'decay' beneath your fingers when you employ more aggressive strategies to reduce code size, like: continuing with register or flag values from preceding code in further, unrelated code; tailoring code to work only for certain ranges of values; double-use or re-ordering of instructions, mixing them from two or more different routines. Once you try to extend the functions of the code, these optimizations break - and you'll wish you had kept a version with the straightforward code.

The new feature is one that I particularly love, because trying to guess future relative branch addresses makes me pause and lose my mojo. This feature allows you to enter an * as an operand for a relative branch instruction with an unknown address, and then * in the future to resolve the original instruction's offset.

*Really* nice!

A similar method is probably adopted by most single-pass symbolic assemblers. Forward references of a label are put in a list, and when that label finally has been defined all its occurences in earlier places are resolved.

As you can see from my monitor primer thread, I've adopted the method of just writing the instruction address (which is always valid for 65xx branches!) as branch/jump target operand, and using the screen editor to keep an equivalent of the list just mentioned as long as the forward branch/jump distance isn't too far. Otherwise, when the forward reference 'threatens' to scroll off the screen I note down the branch, or mark it on the draft paper (you know, the one with all the arrows left and right to denote jumps and branches).

[chysn]

Though 65xx code has the tendency to 'decay' beneath your fingers when you employ more aggressive strategies to reduce code size, like: continuing with register or flag values from preceding code in further, unrelated code; tailoring code to work only for certain ranges of values; double-use or re-ordering of instructions, mixing them from two or more different routines. Once you try to extend the functions of the code, these optimizations break - and you'll wish you had kept a version with the straightforward code.

I know what you mean, I've run into that kind of thing at least once. I try to compensate for this with comments, which I use liberally. But I'm not doing anything too crazy. And I think I'm near the end of what I'm able to do reasonably do. Most of my gains have come from finding that I was doing unnecessary things within a subroutine. I'm a C programmer at heart, so I'm naturally resistant to crossing code between subroutines. When I look at my code uncommented and disassembled, it looks to me like enormous blocks of almost nothing but JSRs.

A similar method is probably adopted by most single-pass symbolic assemblers. Forward references of a label are put in a list, and when that label finally has been defined all its occurences in earlier places are resolved.

If I ever bring this to 4K, I'll probably generalize this feature to other kinds of instructions, with multiple "labels" (*0 - *9, probably) available. I don't know if it needs to get too nuts for a direct assembler.

[Victragic]

Interesting project. One of the features of BBC BASIC that I thought was impressive was the ability to seamlessly include assembly code.

Gimmick? Well, I tend to look at all these things on through the lens of whether they would have been useful in 1982.. I'd definitely have wanted to have it as a tool back then, it would have been fantastic to have, therefore is a worthwhile project now.

I agree with the 'disintegrating code' comment, I've always thought the usual tricks of self - modifying code make it so much more difficult to work on later, but they are almost necessary evils if coding in limited space. Perhaps the strangest trick is the one Microsoft used in it's BASIC in the Vic, with BIT instructions masking out LD instructions to save (anything?) before making the call. It's ugly, but if it was good enough for Mr Gates..

Anyway I digress, will watch with interest.

[chysn]

Perhaps the strangest trick is the one Microsoft used in it's BASIC in the Vic, with BIT instructions masking out LD instructions to save one byte before making the call. It's ugly, but if it was good enough for Mr Gates..

Yeah, with something like that, the more you use the call, the more you save. In this case, they use each error message--on average--twice. So they save one byte (lda#/jmp, lda#/jmp at 10 bytes versus jmp/jmp/lda#/$c6 at 9 bytes) for each error message, or nine bytes all together. It'd be easy for me to say that the loss of clarity isn't worth nine bytes. But I get how important nine bytes can be. If I had nine bytes now, I'd make my disassembler and memory dump tools respond to the STOP key. There's always stuff to do. And it is a pretty cool trick. They did something similar in the memory test code, but I really think that usage was a wash, or slightly worse.

[Mike]

Perhaps the strangest trick is the one Microsoft used in it's BASIC in the Vic, with BIT instructions masking out [...] instructions [...]

Using BIT instructions to mask instructions IMO is a rather benign measure. even if it somewhat complicates code analysis. At least the BIT instruction itself is a tell-tale sign that it might be reasonable to try a disassembly at the opcode address + 1.

Masking off LDx instructions is quite obvious though. Here's a snippet from MINIGRAFIK, it's part of the line routine. It lets the current pixel co-ordinates in $FD/$FE run into the direction of the endpoint in $F9/$FA, or stop when both are equal (and signal that condition to the caller in the Z flag):

Code: Select all

.2417  B5 FD     LDA $FD,X
.2419  D5 F9     CMP $F9,X
.241B  F0 09     BEQ $2426
.241D  08        PHP
.241E  B0 03     BCS $2423
.2420  F6 FD     INC $FD,X

>2422  2C

.2423  D6 FD     DEC $FD,X
.2425  28        PLP
.2426  60        RTS

The whole of the line routine is just 91 bytes in size, excluding the pixel set routine, and it handles all octants with one main loop.

[chysn]

My god. It's only 8AM here in Detroit, Michigan, USA, but this is already a candidate for "Best Thing I'll Learn Today."

I feel like I've been in this situation recently. It always feels so awkward to have one instruction and then have to do a JMP or Bxx over the next one instruction. I'll need to look through my code, but I know this is something I'll use.

I've been personally steadfast in my disinterest in using illegal instructions, but this is a situation where, for disassembly purposes, I could find use for them. If you use the opcode $0c instead of $2c, MINIMon would show the code pretty much as you showed it, except with 0C instead of 2C, while with BIT you see the BIT instruction instead of the DEC.

$0c is the so-called TOP, or triple NOP, which is an absolute addressing mode non-instruction. There's also DOP ($04), which is a two-byte version (zeropage addressing mode). Both TOP and DOP take as many cycles as their BIT counterparts.

Certainly due to the fact that somebody has already thought of this, DOP and TOP are also known as SKB and SKW, respectively.

The irony is that a disassembler that doesn't support illegal instructions would get the best mileage out of this usage of illegal instructions.

[chysn]

Inspired by the above conversation (thank you both!), I added a .byte entry mode to the wAx assembler. A period after the address basically just routes the assembler over to the hex editor:

* Yeah, I know I got the PLP wrong

This feature cost only four bytes to add. Where did I find the four bytes? By removing the question mark after the "unknown opcode" display, which I no longer want anyway, since unknown opcodes are now potentially-useful and editable:

Since I'm just leveraging the existing editor, you can actually add up to four bytes this way.

With the 6502X "illegal opcode" table extension installed, disassembly looks like this. Less clear, in my view:

[Noizer]

Very nice with TOP instead of BIT, no flags are affected.
I think that's the best view

[chysn]

Very nice with TOP instead of BIT, no flags are affected.
I think that's the best view

One idea I had was adding SKW and SKB instructions that use the $oC and $04 opcodes, but lie about the actual addressing mode to the disassembler, making it implied instead of zeropage/absolute.

That way, you’d see the disassembly as

Code: Select all

2420 inc $fd,x
2422 skw
2423 dec $fd,x

[chysn]

I made some pretty big changes in the latest release. Some changes involve disassembly control. It defaults to 16 lines, but you can go shorter with the Stop key and longer with the Shift key (or forever with Shift Lock). Between those and Control, it's pretty easy to see what you want.

I changed some of the wedge characters around to focus on right-hand shiftless controls. So disassembly has been moved to period, memory dump has been moved to comma, and hex-to-base10 conversion now uses $. The hex editor and assembler are now unified to @, so all three types of entry (assembly, hex, text) now use the same command and prompt.

I also spent some time verifying the accuracy of the assembler. It's done in two steps. The first step is to assemble all instructions and all addressing modes with wAx using a BASIC program. If that succeeds, the next step is to compare that program in memory with a binary image assembled with XA, using wAx's assertion tester in a second BASIC program. I included the test suite with the .d64 file. TLDR: Everything checks out: https://youtu.be/nbfO7u3pH1I

[pixel]

Even I am guilty of having provided a Bubblesort to sort fixed-length strings, which then went into nbla000's file browser.

LÖL! At times bubble sort is just perfect.

[chysn]

Even I am guilty of having provided a Bubblesort to sort fixed-length strings, which then went into nbla000's file browser.

LÖL! At times bubble sort is just perfect.

Exactly! Like when you're demonstrating how to build unit tests.