I'm getting to the point with my 65816 assembler where I can start thinking about more than just the core functionality. I'd like to include some checks for obvious problems -- for instance, if you're coding the WDM instruction, you've probably done something wrong. Also, a XCE without a SEC or CLC before should generate a warning as well. Checking for JSR/RTS sequences (to be replaced by JMP) would be another easy optimization to suggest. Does anything else come to mind for the experienced 65816 programmers here? The amount of stuff I'll be able to include in this single-pass assembler will be limited, but somebody out there might be thinking about a two-pass version as we speak ...

In my assembler I implemented a check for DP: if can feed it an address ("LDA label") and asm checks if upper half of <label>=DP and if so generates the two-byte-instruction instead of 3-byte.
Similar should be for DBR/PBR - but lack of time and lack of experience with '816 makes it a little difficult. So that's on hold for now.

Checking for JSR/RTS: you can extend this optimization suggestion to Branch/JMP, Branch/long branch. (Good idea BTW - easy to do in pass 2, I will copy that. THX)

Actually, I can think of reasons to allow all of those. WDM can be used with special, fast I/O hardware for 2-cycle I/O without disturbing registers, similar to the idea of Jeff's single-cycle 65c02 I/O circuits at http://wilsonminesco.com/6502primer/potpourri.html#Jeff . It's possible that one might know the C flag's state left from a previous operation and subsequent branch before XCE (although it would be a rare situation). And although JSR/RTS should usually be shortened to JMP, there are situations in passing data back and forth between routines on the hardware stack where automatically doing the shortening can get you into trouble. If you pass data to a subroutine on the stack, the subroutine expects the return address to be there; but if you JMP to it instead, the subroutine won't know that it's supposed to reach into the stack a different depth to access various data because the return address is not there on top of it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thought so, too, but said nothing, because:

If his assembler issues a warning about it, that indeed might be useful. Nevertheless he should implement some way of turning this warning off (just for a single case or generally).
(In my asm I did it with a "§catch <error_message>:" - it will include the eror/warning in the listing file but not in the screen output. I actually did it that way to test if my asm produces error messages for invalid address modes like inc abs,y on NMOS etc - §catch will produce an error if the error does not appear.)

Yes, this is all warning only, I'm somewhat wary of "clever" machines, especially if I'm the one programming them . Thanks for the suggestions!

You have to be very careful having an assembler rewrite code. Take your JSR/RTS example. What if the instruction before the JSR was a branch making the JSR conditional. For example:

Optimising the addressing modes to use the shortest/quickest instruction is fair enough but you should also provide a way of forcing a particular mode. The WDC assembler (and mine) has various prefixes which allow you to do this. Essential if the address is a dummy and is patched at runtime.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I personally do not want an assembler doing my thinking for me. None of those checks would be of value to me, as the assembler can't possibly know what are my intentions. That sort of stuff is fine with a compiler, where some hand-holding may be useful (all compilers generate diagnostics about dubious things, as well as outright errors). However, one writes assembly language programs to (among other things) create the fastest and tightest possible code. Doing so frequently entails the use of "odd" programming techniques that an "error-correcting" assembler will misunderstand.

As for warning about WDM, Garth already pointed out that the instruction actually has some specialized usages. Also, WDM is benign: it's seen as a NOP and doesn't nothing other than step PC.

Similarly, as Garth noted, the JSR -- RTS sequence may be valid due to run-time branching. Also, as he noted, any subroutine that expects a stack frame prior to entry cannot be JuMPed into, as the wrong word will be pulled for a return address, causing a major malfunction.

My advice, FWIW, is to limit the assembler's error checking to syntactical and addressing matters of the type that would otherwise cause it to emit erroneous code, and assume that the programmer knows what he's doing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The right way to do this - to please all parties - is to have command line flags or other means to make the warnings more verbose or less visible.

And if those do become visible, have some sort of "#pragma yes I intended to do that here" indicators for particular places in code to shut them up on a case-by-case basis.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor