void outchar (char c) {
c = c | 0x80;
asm volatile ("jsr $fbfd\n" : : "a" (c): "a");
}
void outstr (char* str) {
while (*str != 0)
outchar(*str++);
}
void main () {
outstr("Hello, world!\n");
}
lda #$c8 ; ASCII H | 0x80
jsr $fbfd
lda #$e5 ; ASCII e | 0x80
jsr $fbfd
...
Nitpick 2: why ldx #0 txa rts? I would think lda #0 rts is shorter and faster
Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct.
I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value. If that value isn’t used, why spend time setting it?
A assembly programmer also would:
- check whether the routine at 0xFBFD accidentally guarantees to set A to zero, or returns with the X or Y register set to zero, and shamelessly exploit that.
- check whether the code at 0xFBFD preserves the value of the accumulator (unlikely, I would guess, but if it does, the two consecutive ‘l’s need only one LDA#)
- consider replacing the code to output the space inside “hello world” by a call to FBF4 (move cursor right). That has the same effect if there already is a space there when the code is called.
- call 0xFBF0 to output a printable character, not 0xFBFD (reading https://6502disassembly.com/a2-rom/APPLE2.ROM.html, I notice that is faster for letters and punctuation)
On a 6502, that’s how you get your code fit into memory and make it faster. To write good code for a 6502, you can’t be concerned about calling conventions or having individually testable functions.
Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll be content with the string printing taking about as long as it takes, which clearly isn't too long, as they wouldn't have done it that way otherwise. And the loop "overhead" won't be meaningful. (Looks like it'll be something like 7 cycles per character? I'm not familiar with the Apple II. Looks like $fbfd preserves X though.)
I just wanted to use 6502 code (so many seem to be able to read it!) with C side by side. x86 would have worked as well. Where the fastest answer would also be the same construct, assuming the dependency on an external routine.
Also, if you're trying to keep in sync with some other piece of hardware, then just doing it step at a time can be much easier.
Anyway, I have done a lot of all of this sort of code and I am quite familiar with the 6502 tradeoffs! But for printing 15 chars by calling a ROM routine, I stand by my comments.
You know what, I'm gonna nitpick that nitpick: void main() is fully allowed on a freestanding target, which is still standard C.
Given the C standards historically generous interpretation of undefined behaviour and other miscellany, I think it's a reasonable interpretation of the standard to pretend that a target that allows something other than int main(...) is freestanding rather than hosted, and therefore fully conforming.
Isn’t this actually good practice on the 6502? The processor treats the first page of memory (called the zero page) differently. Instructions that address the zero page are shorter because they leave out the most significant byte. Addressing any other page requires that extra byte for the MSB.
Furthermore, instructions which accept a zero page address typically complete one cycle faster than absolute addressed instructions, and typically only one cycle slower than immediate addressed instructions.
So if you can keep as much of your memory accesses within the zero page as possible, your code will run a lot faster. It would seem to me that treating the zero page as a table of virtual registers is a great way to do that because you can bring all your register colouring machinery to bear on the problem.
"An overview of the PL.8 compiler", circa 1976
As in megabytes.
Nearly all of clang and LLVM are linked as libraries.
For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
Bloat making software bigger will in many cases also make it slower.
Also, the UX on Windows 95 was consistent and easy to learn. Now, much software fail on stuff like disabling a button when you have clicked it and the computer is working.
MacOS is on a steady curve to the bottom. It is not alone.
The software bloat and decreasing quality is a serious issue.
macOS icons also used to have distinct silhouettes which made them easier to distinguish, but now everything is a square tile. Screen controls which used to be visible and targetable are now hidden and are harder to hit when they do appear.
It feels like we are still under the tyranny of the (Jony Ivian?) streamlined aesthetic over usability and functionality, as if a library decided to organize books by size and color.
Latency when the system is under low load was definitely better, although a big contributor to that is changes in input and display hardware. But otherwise I'd much rather have today's "bloated" experience over the real world of the '90s.
If you take software from 20 years ago, and run it on modern hardware, it will be instant in most operations.
In the case of Apple, it's often Apple software eating up the benefits of Apple hardware.
Unfortunately subtle differences (such as improved reliability/security or a streamlined workflow) are lost in the computing market, where people are attracted to the new and shiny rather than the old and usable. Also designers like to mess with things.
And yet Electron apps often garnish that memory bloat and computational inefficiency with sluggish performance and a clunky user experience.
It's a shame when an 8GB Mac mini doesn't have enough RAM to run apps comfortably. Of course there's a bit of a corrupt bargain going on between bloated software and Apple since the latter wants to upsell you to a more expensive model.
Monthly bills are stopping me. Can I use Apple's MPW C compiler to build for iOS?
I wouldn't consider an iPad Mini 1st generation to be very retro, but I still need to run a MITM proxy for it to be able to browse Wikipedia(!).
You need to search for it on old ftp sites.
> For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
The compilers have "evolved". Compiling old code is challenging, to say the least. I do compile old programs when the new seem to explode: xpdf, xsnow.
Compiling old compilers is impossible because they rely on ancient kernel headers.
Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.