Another point of view: ideally it would just be "Age". But in languages that don't have the ability to "open" scopes, one might be satisfied p.Age, being "the age". I've also seen $.age and it.age, in languages with constructs that automatically break out "it" anaphora.
TT will either make me a chip I can run, a chip I can run with some workarounds, or garbage. Only time will tell!
As for Claude, honestly, as a partner. We bounced ideas off each other, while I provided overall direction for the project. It was finishing up a design I had started and aborted last year, but we did build this from scratch. I had some good ideas, Claude had some good ideas, but Claude did almost all of the actual grunt work. Looking back, Claude's tactical decisionmaking was often better than mine, but my strategic decisionmaking was far superior. I would also occasionally have to interject when it was "freaking out" and offer a sounding board to help it solve whatever problem it was working through.
To me, it's plausible one might be able to make a similarly small RISCY-V02 on a 70s Rubylith NMOS process with dynamic logic, using pass transistors and tristate busses, all laid out by hand. But I definitely can't do that, and even if I could, I'd have no way to validate that it actually works.
Best I could do was an A/B comparison on a modern process: a clean Verilog model of RISCY-V02, and a clean Verilog model of a 6502, both run through a modern synthesis process for TinyTapeout. Same slosh, inoptimality, and behavior. So, this is a static CMOS design, like the 65C02, on a modernish process node. That being said, the 65C02 had around 11K transistors, so we're not too far off.
This establishes horseshoes and hand grenades plausibility, but basically nothing else. But, it's also a pretty nifty CPU design if I do say so myself!
Hey, llvm-mos maintainer here. I actually work on LLVM in my dayjob too, and I don't particularly want llvm-mos upstream. It stretches LLVM's assumptions a lot, which is a good thing in the name of generality, but the way it stretches those assumptions isn't particularly relevant anymore. That is, it's difficult to find modern platforms that break the same assumptions.
Also, maintaining a fork is difficult, but doable. I work on LLVM a ton, so it's pretty easy for it to fold in to my work week-to-week. And quite surprisingly, I used AI to help last time, and it actually helped quite a lot!