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!

Lol? https://github.com/mysterymath/llvm-mos/tree/regalloc

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?

See https://discourse.llvm.org/t/rfc-enabling-fexec-charset-supp...

There's a lot of discussion about this; practically changing the execution character set isn't trivial, and it's not necessarily even a desirable feature. Even with full -fexec-charset support, it still makes sense to provide compile-time translation from Unicode to target strings. For example, Commodore PETSCII makes vastly more sense as an execution character set than a source character set.

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.

I'm definitely supportive of the original "Symbols for Legacy Computers" effort. We've been able to make great use of it in the llvm-mos toolchain for legacy systems; we can directly encode special characters for these computers directly in the UTF-8 source text of modern C++, then use C++ user-defined string literals to convert them to their original byte codes. It's an aid to hobbyist use and preservation of these systems, and thankfully, there's a relatively small fixed number of them to support, especially relative to the space available in Unicode. It should unlock quite a few of these kinds of projects for exploring and experiencing the history of computing.

https://llvm-mos.org/wiki/Character_set

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).

Meh. Rust's safety guarantees typically depend on:

- Soundness of their semantics at a conceptual level

- Correct implementation of the semantics in rustc (in Rust)

- Correct translation of those semantics to LLVM IR targeting OS syscalls in rustc (in Rust)

- Correct translation of LLVM IR to native code in LLVM (written in C++)

- Correct implementation of OS syscalls (typically in C)

Python's safety guarantees typically depend on:

- Soundness of their semantics at a conceptual level

- Correct implementation of the semantics in CPython (in C)

- Correct translation of C to LLVM IR targeting OS syscalls in Clang (in C++)

- Correct translation of LLVM IR to native code in LLVM (written in C++)

- Correct implementation of OS syscalls (typically in C)

Both are typically contingent on correct implementation of a huge swath of C/C++ and Rust code. Even if the entire stack were written in Rust, it still wouldn't be sufficient to guarantee memory safety, since bugs anywhere in the stack could introduce memory unsafety into compiled Rust code.

Rust's guarantees come entirely at the first two layers of the stack: If the semantics are sound, and the semantics are implemented correctly in rustc, then the generated LLVM IR (treated abstractly) has memory safety. Python has similar guarantees: if its semantics are sound, and the semantics are implemented correctly in CPython compiler and interpreter, then the resulting execution of the interpreter has memory safety.

This is a bit tough I'm afraid; while I'm very appreciative of the effort, I don't actually like the parts of the series that I've read very much.

The overall complaint is one of structure; prose flows from one point to another without my being able to build a model of where the argument is going, where it came from, what's an essential detail, what's an interesting aside, etc.

It's a common fault in technical writing, maybe the most common in my experience. IMO, well-organized writing is a "parasocial" endeavor: there's a bit of mind-reading involved. One needs to get inside the head of their audience and try to predict their mental states. Why did they click on this? What questions do they have? What preconceptions would cause them to immediately close out? How can you answer those concerns as quickly as possible, and lead gradually into a more nuanced discussion (if they so desire). If they're not likely to desire it, can you convince them to?

The answers to these kinds of questions about a brand new reader should suggest a thesis. Similar reasoning about a reader who has read the thesis should suggest the content of an abstract. And so forth, for an introduction, a guide to contents, etc. After that, presuming some skimming helps too.

I was just such a person. I was taught that being a YEC meant that we were the only ones who earnestly sought after the truth. The world was blind, and by rejecting a corrupted authority and assessing the world on their own we were more likely to arrive at the truth.

In college, I successfully took apart the arguments of the peers who tried to dissuade me from my beliefs. They weren't good arguments; they had no idea why what they believed was true, but I did. This reinforced my views more than anything.

But, this earnest searching for the truth also led me to take philosophy of science and religion courses at my university, and that was the first time that I actually learned the mechanics of what went into the scientific method, and particularly why that method tends to achieve its goal of arriving at the truth. My entire primary and secondary education had never contained an discussion of this, nor had anyone I'd ever spoken to known it.

I also came across the talk.origins pages (https://www.talkorigins.org/faqs/faq-welcome.html), which contained the first full exposition I'd seen of not just the theory of evolution, but also the tremendous host of failed falsification opportunities that support it. I was pulled into a more correct view of the world kicking and screaming, by the same forces that had kept me away from it for my entire life.

I can't speak to how common my experiences are, but I'm endlessly grateful to those who didn't presume that there wasn't anyone like me out there. Admittedly I do have a stick up my butt about this, since it's a refrain I hear often. But I suspect that many of the flat-earthers out there are budding scientists in disguise, poorly served by their environment, and waiting to be freed.

Duke3D isn't a raycaster; it's a portal-based quad rasterizer. Wall quads are forced vertical, and floor quads are rasterized using a neat trick. The renderer computes successive lines of constant distance along slooped floor surfaces, then draws textures using affine scaling, which is correct along those lines. The portal walls clip the draw of successive sectors, which solves the hidden surface problem.

https://fabiensanglard.net/duke3d/build_engine_internals.php

The story is a little more complex than that; the semantics were internally consistent, but foot-gun-ey, and they could technically be taken to match GCC's documentation of how they behaved, depending on an unfortunately ambiguous phrase in their docs.

The old semantics also matched GCC's actual behavior; when we brought this up in a GCC issue, those present decided that GCC's behavior was wrong, but the appropriate maintainer couldn't be reached for a final say. The issue is still hung like that.

There were also a few other folks trying to do the same kinds of whole-program call graph analysis this enables, IIRC for GPU purposes. So, there was a lot of conflicting opinions about how this should work, a lot of uncertainty, all the recipe for a big long endless thread.

EDIT: This is of course my extremely biased take on the proceedings. This was also the first and only "open source kerfluffle" I've so far been direct party to; I've seen these come and go on mailing lists before, but I was surprised how different it felt to actually be inside one.

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.

I'd actually like the llvm-mos to do an automated AoS to SoA analysis and rewrite, but haven't gotten around to it yet. There aren't any intrinsic theoretical obstacles I'm aware of though; it's just difficult code to write.

Now that this has come up again as the stock reason "you can't do C well on the 6502", replacing the stack, the zero page, and the register set, I'm probably going to reprioritize it and put the register allocator on pause.

In LLVM-MOS, we mainly struggle with its register allocator; the rest of the backend is really quite reasonable.

The "Greedy register allocator" in LLVM is a just finely tuned priority allocator with nice live-range splitting. It works great for zero page cache locations, but it's just not tuned very well for tight register classes like those involving the processor's three architectural registers. I've half a mind to implement Hack's SSA-based register allocator in LLVM to use on A, X, and Y; this would clean up the oodles of spurious copies LLVM-MOS spits out in the worst cases.

I maintain a LLVM backend for the 6502: https://godbolt.org/z/6EWEb6c5E, https://llvm-mos.org

I love compilers, and I work on LLVM full time at my day job. I love bringing modern tooling and techniques to an older environment where they very much don't belong; the juxtaposition of the two is very satisfying to me.

Que? We don't compile to a virtual machine, we compile to plain 6502 assembly. We do use 32 bytes of the zero page as a de-facto register file, but that's not at all uncommon in hand-written assembly either, it's just usually less explicit.

The prevalence of self-modifying code also heavily depends on what community of 6502 developers you're part of. It's relatively niche on platforms where most code is in ROM, e.g. most game consoles. For example, the NES only has 2KiB of RAM, but can support upwards of 512KiB of ROM, so it's downright wasteful to place code in RAM.

As for 2 and 3, LLVM-MOS lifts local variables to global memory or the zero page wherever possible, and is able to use function aliasing information to allow the globalised versions of local variables in different functions to share the same memory.

This has come up off and on, and it's looking increasingly unlikely. I've had to do some nasty surgery to the loop strength reduction pass, and I haven't yet found a way to generalize it.

Still, I'm not ruling it out, it just never seems to be very high on the TODO list. I've also started to do more work upstream whenever the situation calls for it; quite a few of the improvements we've done to LLVM do generalize to other targets, so much of that can and should be upstreamed indepenently.

The AtariAge results are fairly out-of-date; I think that's even before we started doing whole-program zero-page allocation.

The only real 6502-specific C caveat left for llvm-mos is that you should strongly prefer structs of arrays to arrays of structs; and that's not even that 6502-specific. Otherwise, standard C gives fairly tight assembly.

That being said, every couple hundred lines of generated assembly for any reasonably-sized C program will contain at least one WTF, from a human point of view. Removing those WTFs one at a time is the long tail of a compiler engineer. Still, I'm not going anywhere!

Wiki: https://llvm-mos.org GitHub: https://github.com/llvm-mos/llvm-mos-sdk Slides: https://llvm.org/devmtg/2022-05/slides/2022EuroLLVM-LLVM-MOS...