Source Speedrun Tools: practice tools and handy features for Source Engine games https://qdb.woz.blue/mike/sst/atom?h=v0.18-BETA 2026-02-16T19:11:24+00:00 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-29T16:28:28+00:00 urn:sha1:2088b61f3d6053d3879dcfcbe91c00157d050e16 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-13T18:26:51+00:00 urn:sha1:40f9d989df2c1ff2f567656ccbdbfc0d97e34a77 This lexer is being written as a chunklet, not quite quite complete yet as it lacks some functionality to make it generally useful for things, but good enough for the gluegen use case now. So it's in the repo now and we can go ahead and use it for this instead of having this hacked-to-pieces third party thing that's nowhere near as efficient. In the future the goal is to have a decently usable library for any sort of C metaprogramming needs, not just within this project. This design does the data-oriented thing of storing as little about each token as possible (just 5 bytes), and re-lexing specific pieces only when necessary. In some cases, full validation of correct syntax is only possible through this secondary step. Since the use case is metaprogramming and code-generation rather than the reimplementation of Clang, this slight sloppiness in validation doesn't seem too bad. It's been a while since I did a proper performance measurement of this code but in some crude tests I did in the past the primary tokenisation step was running at well over 500MB/s, which is fast enough for me. It's possible that this version is a tiny bit slower due to the added complexity of making UCNs work. UCNs, incidentally, are one of the dumbest features of C by far. However, unlike trigraphs - which this lexer does not handle - UCNs are still in the language, so it's kind of sort of necessary to support them. It's probably still possible to come up with a faster design with some SIMD trickery, but the main loop is currently branchless and the lookup tables are too big for the SIMD lookup things, so that seems kind of hard. A separate SIMD path for whitespace or comment runs seems dubious as it would introduce branch mispredictions everywhere. I also made previous attempts to unroll the main loop and every attempt just made it slower, so I guess code size is a significant factor. Optimising the secondary tokenisation of identifiers (and later numerals and string/character literals once those are handled) is still on the cards, but since that happens less often, I don't know how much difference it'll make. At any rate, in a multithreaded context this thing would already come pretty close to SSD speeds, if open-read-close syscall overhead doesn't get in the way first. I imagine it's fast enough for anyone who hasn't *already* written something faster. 2026-02-16T19:11:24+00:00 Michael Smith mikesmiffy128@gmail.com 2025-12-18T23:33:26+00:00 urn:sha1:f386f2a1fcae885967278710fe997c56e2183476 Saves multiple kilobytes, somehow. Unlikely to make much of a performance difference since it's mostly init/shutdown stuff. 2025-11-24T03:23:22+00:00 Michael Smith mikesmiffy128@gmail.com 2025-11-24T03:19:49+00:00 urn:sha1:508878ff0a9e4cd8528727c41819bc2d70b33dd0 Quick unused header cleanup pass while we're at it. 2025-08-03T14:29:48+00:00 Michael Smith mikesmiffy128@gmail.com 2025-08-03T14:29:48+00:00 urn:sha1:b11cf48853bc4eccde60bc82180025f0797fa823 Turns out, there's no need for the trailing underscores. Plus, glibc does some stupid stuff with __attribute__ for non-GCC compilers. Not that that matters here, but it seems like a good practice just to use the forms that never have such problems. And it's shorter too. 2025-04-16T01:21:43+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-16T01:16:57+00:00 urn:sha1:7621b76c7081049b6b93ee679cbd786dbb7d49a4 I had at one point tried to macrofy the repetitive functions. After being talked down from that madness, I LSP-expanded all the macros out and went through rewriting the crazy expressions into constants. Except those two for some reason, because I'm blind I guess. Thanks bill for pointing this out. 2025-04-07T20:31:32+00:00 Michael Smith mikesmiffy128@gmail.com 2025-04-07T20:31:32+00:00 urn:sha1:58b495650f7613cdebfe78fff9de2b99556f1998 They're legally unnecessary as far as I know, and kind of annoying to maintain on a long-term basis. This was done with the consent of all 3 other contributors, in case anyone was wondering. 2025-04-06T19:59:36+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-17T00:02:10+00:00 urn:sha1:b0d2eb687de6cf4e9e8c3dcd8f98fdff3a444f4f 2025-04-06T19:59:36+00:00 Michael Smith mikesmiffy128@gmail.com 2025-03-11T23:01:02+00:00 urn:sha1:8575dbb87b17841ac13279f73a6ffd8e02788143 - Add reverse-put functions for stack-based and/or left-pad-inspired use cases. - Fix an incorrect return value. - Clean up the doc comments, fixing a few errors and omissions. - Make some trivial functions static inline. 2024-08-23T19:37:37+00:00 Michael Smith mikesmiffy128@gmail.com 2024-08-03T22:40:31+00:00 urn:sha1:83da606072ce272eb053d4e1497d77e647cfecae My new programming style is branch hints. All non-confusing branches must be hinted when I can be bothered. It's faster, sometimes, maybe. Also, start trying to use more signed sizes in at least some of the places where it makes sense. Unsigned sizes are surprisingly error-prone!