mysterymath

Beeeecause this was a lecture delivered at a Catholic philosophy/theology conference?

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!

You're talking about different 80s. On workstations and Unix mainframes, beasts like Smalltalk and Objective C roamed the Earth. On home computers, a resident relocatable driver that wasn't part of ROM was an unusual novelty.

Ah thanks, that's what I was looking for.

There's something very hinky about this post. It links to efabless.com/notice, not efabless.com direcly, and there's no information about this on efabless.com proper. The title of the notice page is also "Website Title". Not to don my tinfoil hat prematurely, but might this be an attack on efabless's web hosting?

This wouldn't have worked for the llvm-mos use case I mentioned; the actual identity is the useful part. I'd expect each of these symbols was associated with a numeric code on a legacy computing platform, and having a Unicode assignment makes it possible to machine-convert text from these systems to and from Unicode.

There's an old saying: "Yesterday's AI is today's algorithm". Few would consider A* search for route-planning or Alpha-Beta pruning for game playing to be "Capital A Captial I" today, but they absolutely were back at their inception. Heck, the various modern elaborations on A* are mostly still published in a journal of AI (AAAI).