When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kitty.jpg, though. It’s since been changed again to rotating pictures and references to the original are gone.
This is really cool! The filename on certain Amazon 404 pages (eg. https://www.amazon.co.jp/404) is still kailey-kitty.gif (but the image has been replaced with a standard icon).
Your optimizing compiler today will actually optimize. LLVM was recently ported to the 6502 (yes, really) [1]. An example:
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");
}
That is compiled to this:
lda #$c8 ; ASCII H | 0x80
jsr $fbfd
lda #$e5 ; ASCII e | 0x80
jsr $fbfd
...
Unrolled loop, over a function applied to a constant string at compile time. An assembler programmer couldn't do better. It is the fastest way to output that string so long as you rely on the ROM routine at $fbfd. (Apple II, for the curious.) Such an optimizing transform is unremarkable today. But stuff like that was cutting edge in the 90s.
I understand your point, but LLVM-MOS is a bad example. You gain LLVM’s language optimizations, as you point out. But LLVM’s assumed architecture is so different from the 6502 that lowering the code to assembly introduces many superfluous instructions. (As an example, the 6502 has one general purpose register, but LLVM works best with many registers. So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used.) It’s of course possible to further optimize this, but the LLVM-MOS project isn’t that mature yet. So assembly programmers can still very much do better.
So LLVM-MOS creates 16 virtual registers in the first page of memory and then generates instructions to move them into the main register as they are used.
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.
I understand your point but the beginning of the zero page is almost always used as virtual registers by regular hand-rolled 6502 applications. So it's pretty normal for LLVM to do the same, it's not an example of LLVM doing something weird.
Doubtful, given the JSR comes from an inline asm. You’d need to code the call in C (with an appropriate calling convention, which I don’t know if this port defines) for Clang to be able to optimize a tail-position call into a jump—which it is capable of doing, generally speaking.
No. The compiler knows that trick for its own code :) not sure about introspecting into the assembly (I think LLVM doesn't do that). But either way, standard C returns int of 0 from main on success. So: ldx #0 txa rts
Nitpick: this isn’t standard C (it uses void main, not int main)
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.
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.
I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0.
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.)
We did a lot of loop unrolling and self modifying code back in the day, when making demos for the C64. The branch is really expensive. For example, clearing the screen you might use 16 STA adr,x and then add 16 to X before you branch to the loop.
Indeed, in some cases you want the unrolls. The 6502 is good in the twisties, but if you're trying to do any kind of copy or fill then the percentage of meaningful cycles is disappointingly low, and the unroll may be necessary. 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.
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.
Yes, I compiled with -O3 for maximum speed. That would be an unusual flag choice in most cases.
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.
> Nitpick: this isn’t standard C (it uses void main, not int main)
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.
Yep, llvm-mos-sdk is explicitly freestanding; the libc functions in the SDK follow the hosted C standard, but they don't add up to a hosted implementation. The only known C99 non-compliance is the lack of floating point support, which is actively being worked on.
Binary size on a desktop OS is almost totally irrelevant in practice. Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't.
People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive.
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.
I see this sentiment again and again, but the Windows 95 experience I remember included frequent spinning hourglasses, blue screens of death from faulty drivers, everything grinding to a halt when memory is near exhaustion or files are being copied between disks, tons of third party applications (and even Microsoft applications, like Office) that disregarded the Windows UI standards, constantly having to run CHKDSK and defrag, not to mention malware/virus vulnerability...
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.
Thing is, our computers are magnitudes of orders faster than 20-30 years ago. Why isn't our software orders of magnitudes faster? I'll settle for just 10 times faster.
If you take software from 20 years ago, and run it on modern hardware, it will be instant in most operations.
Clock speeds certainly aren't orders of magnitude faster than they were 20 years ago. The vast majority of the performance improvements of the past two decades have gone into improved capability, stability, and security. I don't consider streaming 4K video to be "bloat" personally.
Let's not forget the reinstalls to have the system perform properly again. I must have installed Win94 dozens of times over the years. I've never fresh-installed OS X once. I frankly don't even know how to do that with the current version.
I still think iOS was more fun in the Forstall-skeuomorphic era, and screen elements were easier to differentiate.
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.
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.
> Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't.
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.
Binary size, yes, since that's just sequentially reading bytes from an SSD. What sucks about modern software is input latency and overall responsiveness.
I would love to, if things actually worked on it! Since everything is HTTPS now and you need TLS1.3 for many things, running very retro things for daily usage is next to impossible.
> There’s nothing stopping anyone from going back and using all of that old software exclusively.
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.
That's wonderful to see. Also interesting to see the site performance comments around different components.
Another anecdote: somewhere in that time period we (Prime) were using comments for various metadata and pre-release and post-deployment checks would verify the comments were in place. The team responsible for the edge proxies decided they were going to rewrite all the HTML going out on the fly to remove extraneous comments and whitespace in an effort to reduce page-size.
In the middle of testing a release all of the tests related to a particular feature started failing and (I believe) different devs were getting different HTML on their systems (the feature wasn't rolled out to every session). Our QA team was extremely pedantic in the best way possible and wouldn't allow the release to continue until testing could complete, so we had to track down the responsible parties and get them to dial down their transformation. They eventually tried again without stripping comments, but I can't imagine much was saved after compression without much of anything removed (they might have been rewriting other tags as well).
I know you’re joking, but she wasn’t 18 yet before they changed the picture.
AFAICT, kids own the copyright to things they create[0], but guardians are responsible and can use it on the child’s interest. IANAL, consult an attorney, etc., etc.
On the other hand, I despise the mock playfulness exhibited by, eg, Slack. It’s such a frustrating environment for me - I feel like it’s not-so-subtle attempts at promoting engagement over presenting the content fill me with rage. I want my tools to fade into the background.
When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kitty.jpg, though. It’s since been changed again to rotating pictures and references to the original are gone.