There's a thread over on Stardot where with some cooperative effort, some few hundred bytes are shaved off a 16k ROM program, to make room for more features.

There are several examples given of specific changes, including
- making use of 65C02 opcodes such as BRA and STZ
- changing JSR then RTS to a JMP
- changing JMP to BRA
- re-ordering routines to allow fall-through instead of JMP or BRA
- pulling common code into subroutines or jumping to common postambles
- inlining subroutines used only once
- rolling up repetitive code into loops
- reorganising loop code to use fewer operations
- removing unnecessary operations
- removing dead code
- making some not-so-important features conditionally included in the assembly

There may be nothing very new in there for experienced 6502 coders, but it might be worth a look. I know I enjoyed reading it through! If there are some more tactics not listed above which merit a mention, feel free to discuss them in this thread.

Also notable is the use of some automatic analysis to find opportunities - not quite automatic peephole optimisation but heading in that direction. (In this case a couple of Python scripts.)

Perhaps this is a good place to join the thread:
http://stardot.org.uk/forums/viewtopic. ... 44#p131544
There are four flavours of the ROM being built - it's a filesystem for the BBC Micro, with drivers for one or more of several devices: floppy, IDE drive, bit-banged SD Card.

Another possible way to view the changes is to review the commits made in git.
https://github.com/ZornsLemma/ADFS/commits/master
or possibly this branch:
https://github.com/ZornsLemma/ADFS/commits/scratch2
(You'll also see changes which improve the organisation, the labelling, or the commenting of the source, which is ultimately derived from a disassembly of an Acorn ROM.)

(The source format used is BeebAsm, which allows for structured assembly coding. It would be nice if we could refrain from discussing syntax preferences in this thread! You might need to know that & introduces a hex number in this dialect.)

Hat-tip to hoglet for bringing this thread to my attention.

For certain types of code, something like Sweet16 can really save bytes. Nothing beats adding another layer of abstraction.

Something like Sweet16 come into my mind as well

I've onced squeezed 4 char into 3 bytes using caps-only 6b ASCII. But I haven't look at the source code, whether there are enough messages to have some refund for this.

3:2 encoding of 6502 mnemonics in machine language monitors has been used almost as long as the 6502 has existed. The technique reduces a three-character mnemonic into 15 bits. "Characters" in this case means letters of the alphabet, not numerals, punctuation and whitespace. Reversing the process yields the uppercase form of the mnemonic. I use this technique in Supermon 816. The technique could be extended to compress four characters into 20 bits, five characters into 25 bits, etc.

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

You might be interested at this (partly written by me): http://wiki.nesdev.com/w/index.php/6502_assembly_optimisations

You pretty much summed everything up, but be careful:


Unfortunately this will likely end up with spaghetti code, as the different routines will not be ordered in an "human-friendly" order. Also you seem to assume 65C02 instructions are available - it's great if they are available to you but when doing NES development they're not so I'm not used to this.

Also you forgot to mention an optimisation I use all the time, use ADCs and SBCs when you know the state of the C flag as much as possible. Normally you need "C" to be clear for addition and set for substractions, but for immediate values this is not needed as you can compensate the immediate for it if C is the other way around. I sometime even move code so that an addition is done somewhere where "C" flag status is known.

Good point - knowing the state of one or more flags can be very helpful, especially on an '02 which doesn't have BRA.

It just happens to be true with this project, that although the Beeb is an '02 machine, the project is for the Master (a successor machine) which is a 'C02 machine.

One thing which can go wrong, of course, is that in the process of reordering some branches can go out of range and turn back into JMPs.

You'll notice at one point in the thread the BIT trick is used to get some bytes to do double-duty, but the consensus was that this is too tricky a trick to be retained!

Another tactic to note: once in a while the code is found no longer to be working, and so bisection in the change control history is used to find the breaking change.

Another thing to note is that just a few parts of the code are timing critical, and need to be not too slow, or even not too fast.

And another favorite, even when BRA is unavailable in NMOS platforms, is to convert JMPs to conditional branches, by analyzing known states of the various CPU flags. This sometimes involves reordering operations so that the last one leaves a flag in a known state.

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

Bregalad, do any of the Nintendos use 65c02? If so, it would be good to add a section at the bottom of that page for CMOS. For example, on that forum (NesDev), I keep seeing CLC, ADC #1 where INA could be used which is 1/3 as many bytes and half as many cycles, and LDA #0, STA where STZ could be used. Another one to add even to the NMOS part is removing the CMP #0 after anything affecting the accumulator, or the CPY #0 after anything affecting Y, or the CPX #0 after anything affecting X.

_________________
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?

The original NES just had the NMOS instruction set, sans BCD support. It was second-sourced through Ricoh, and as part of a low-level console platform, they didn't muck about with the ISA in the various hardware revisions.

The Game Boy was z80-ish. The SNES had a 65816, so that would be the first one that would subsume the 65c02 instructions, unless there's some smaller platform or maybe expansion cart I missed.

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

I believe the NEC PC-Engine/Turbografx-16 used a 65C02 derivative, though.

Yes -- the Hudson Soft HuC6280.

The Wikipedia article says, "The HuC6280 contains a 65C02 core which has several additional instructions and a few internal peripheral functions such as an interrupt controller, a memory management unit, a timer, an 8-bit parallel I/O port, and a programmable sound generator. [...] The HuC6280 has a 64 KB logical address space and a 2 MB physical address space."

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

We've mentioned the 6280 here before, although I'd forgotten it.



Previously, Jeff, you were quite excited about the T prefix!



There's an opcode matrix here.

Hah! I hadn't forgotten about the T prefix. But my bass and I did a bar gig last night -- fun, but nothing fancy -- and I was pooped by the time I (we) got home. That's why there's not much detail in my post. Thanks, Ed, for tracking down the supplementary info.

The Mitsubishi/Renesas 740 microcontroller family also features the 'T' mode for for memory-memory operations. Dieter posted a Renesas PDF here.

The 740 family treats 'T' as a mode -- you use the SET and CLT instructions to turn it on and off. But with Hudson Soft's chip the T thing is transitory. The SET instruction turns it on, and it turns itself automatically after the following instruction. So, SET is used as a prefix.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks for the pointer to that thread Jeff. I see the STM8 gets a mention there. I think it's quite interesting to see some concrete choices that various outfits have made, and actually taken to market. It's very easy to speculate about a wider stack pointer, or a prefix byte, but here we see these things actually being done. Even so, we can't tell how attractive the result is, without working with that device.

No.

That's because they couldn't (and can't) be used.


This is quite obvious, not even an "optimisation".