| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Brought to my attention by Hayden just in time to avoid shipping
something buggy.
What I'd give to be able to run proper tests on all this code with UBSan
or similar. I do too many stupid things like this all the time.
More annoying than that is that is apparently this was spotted by one of
them clankers. I've plenty of reasons to be unhappy about that, but
then, what am I gonna do, refuse to fix the bug?
|
| | |
|
| |
|
|
| |
Thanks bill for finding that offset.
|
| |
|
|
|
| |
It served its purpose long ago, and doesn't even build now. Can always
fish it out of history and clean it up if we ever need it again.
|
| |
|
|
|
|
|
| |
Happened when I was getting rid of all the memcpy calls. Must have been
asleep. As usual. Sigh.
Thanks Hayden for spotting.
|
| |
|
|
|
|
|
|
|
| |
Committer's note: tweaked a little bit from Hayden's original code, but
after some back-and-forth testing it seems to work as well as his did.
Might benefit from some further tweaking/micro-optimisation later, but
for now it's good enough to get a release out ahead of the L4D2
community race happening this weekend.
|
| |
|
|
|
| |
Probably self-explanatory. I was finding more use cases for the
__builtin_memcpy_inline thing but boy is that ugly.
|
| |
|
|
|
|
| |
At some point in development, there were a couple of file loading
functions that used this, but they were never committed, so this typedef
has essentially always been redundant.
|
| |
|
|
| |
God I hate Microsoft's stupid crappy C headers. So broken.
|
| | |
|
| |
|
|
|
| |
Based on an earlier patch worked on by aciidz and bill, but I found an
easier way to do it, with less asm-searching for internal stuff.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The bug was causing a crash if the plugin was reloaded while in a map.
Thanks Hayden for reporting.
|
| | |
|
| |
|
|
| |
Forgot to do this immediately after the 0.18 release; oops!
|
| |
|
|
|
|
| |
I always used Neovim where this seemed to work but recently switched to
Vim where it doesn't seem to work. I've now tested it in both and it
seems fine. All zero other users of this script can now rejoice!
|
| | |
|
| |
|
|
|
|
|
|
| |
If a demo already exists, add an additional number to the name to try
and resolve the conflict rather than just failing to record.
Also, print the name of the first recorded demo again once recording is
done, to make it easier to find the correct thing to submit.
|
| |
|
|
|
|
|
| |
According to some reading I did recently on hybrid locks, a value of
around 40 is optimal, or at least was at one point. It might have
changed in more recent years and I have by no means made any effort to
tune the value, but it seems clear that 1000 is way too high.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will need to be accompanied by the publication of my toolchains
repo at some point which has scripts to set up fixed versions of MSVC
and LLVM, with way less space wasted than the official distributions
thereof. Also that'll become necessary for a period of time until I
figure out why LLVM 22 and 23 are unable to link SST now; we are stuck
on 20 for the foreseeable future which makes having a self-contained
thing quite helpful.
This change also includes a couple of other build script improvements
too, most notably debug builds without having to edit the damn script
every time.
|
| |
|
|
|
|
|
| |
The SHUNT craziness I was doing triggers a warning with more recent
Clang versions. Simply move the size into the macro to avoid the
tentative definition abuse, which is probably less confusing (when
combined with the new macro name, ARRAY) and also shuts the compiler up.
|
| |
|
|
|
|
|
| |
I believe this was a regression in the OE support added in 0.15, so it's
been here a while. We don't have a lot of clamped cvars so I guess maybe
nobody noticed for a while. I just happened to find it while testing
other stuff. Quite a silly mistake but an easy fix.
|
| |
|
|
| |
Simplifies ac.c just a little bit.
|
| |
|
|
| |
To be enhanced and extended later!
|
| | |
|
| |
|
|
|
|
| |
Put all the cvars together contiguously; then we don't need to generate
lots of individual calls to extfree() and can instead simply iterate a
fixed-sized array.
|
| | |
|
| | |
|
| |
|
|
|
| |
There was never really much point in this, and it probably slowed things
down a little bit, though not a lot.
|
| | |
|
| |
|
|
|
|
| |
This isn't really making a difference right now but maybe it will in
future builds with different section padding or LTO optimiser
interactions or whatever.
|
| |
|
|
|
| |
Mostly only affects Linux, which doesn't even have a working build at
the moment, but still, noticed it, might as well fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are a little different than the ones we were using privately
before and will require some one-off hopefully straightforward
copy-pasting for existing developers. But hopefully this'll remove some
friction from using the thing across the board.
I'd still like to investigate smoother auth methods in the future. The
SSH key idea seems like a good one, but there's some annoying obstacles
there. There's also the idea of having the Discord bot send people
tokens. For now, it's still just manual, which is probably good enough
for quite a long time, to be honest.
This also includes the Sorse Tecknoledgy Committy Discord link, because
I've kind of not done well to advertise the existence of that thing. It
has always been technically open the public, except many people probably
don't know it's there.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now everything is either explicitly a rep thing, or explicitly some
other small run of reasonably efficient instructions. No library calls
or function call overhead of any kind. Code size remains nice and small.
Ban a few other bad libc functions while we're at it. More can be added
later if we decide that's a useful idea.
This will require some discipline and workarounds to cope with Clang's
tendency to shove mem* calls in places you don't want them even when you
tell it not to. Well, c'est la vie.
I'm a little nervous that the __builtin_memmove() usage in shuntvars()
could still one day emit actual library calls. It appears we're not
importing memmove() from anywhere at the moment, though. So I guess it's
good enough for now.
Also I had to get rid of alloca() in con_.c but that was kind of bad
anyway, so that's fine.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason the DLL got a tiny little bit bigger again but that's
fine. This will make orig_ calls more efficient in the inline case, and
also make it harder to screw up and hook the wrong thing by mistake.
Self-explanatory-ish, apart from the fact it's a fairly large API change
of course. And it relies on some more bonkers assembler directive
hackery.
But it works!
The only complaint one might have is that the featsetup functions no
longer take an explicit string which occasionally yields slightly less
perfect error messages, but I've decided this isn't really a problem and
makes the API nicer to use. It's a tradeoff, innit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Saves multiple kilobytes, somehow. Unlikely to make much of a
performance difference since it's mostly init/shutdown stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Does away with the need to mark a region as executable on load.
Also allows the self-modified stuff and hook trampolines to fit in the
same page, so we take up ever-so-slightly less memory.
Unfortunately I had issues getting the test binary to build correctly
and eventually decided to give up as it wasn't testing much of value
anyway.
Also note that the build now allows for .c and .S files with the same
basename, which required renaming the .o files, so you might want to
clean out your .build/ directory before building this one.
|
| |
|
|
| |
Saves 512 bytes of useless padding. Oops!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Kind of unpleasant and probably something to revisit at some point to
see if there's a more straightforward approach we can come up with.
|
| | |
|
| |
|
|
|
|
|
|
| |
I screwed up merging Evan's changes, and also didn't have that one
REQUIRE_GAMEDATA for some reason, and also didn't test actually turning
on the sst_inputhud cvar once everything had loaded fine in testing.
Unlucky, I guess. Better testing might still have caught it.
|
| | |
|
Michael Smith
Hayden K
