| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Never tested until I started launching Half-Life 2, lol.
|
| |
|
|
| |
Thanks again to Evan Lin for finding this and sending a patch over.
|
| |
|
|
| |
Quick unused header cleanup pass while we're at it.
|
| | |
|
| |
|
|
|
| |
Pretty hacky for now, but not the worst thing in the world. Can always
be tidied up later.
|
| |
|
|
|
|
|
|
|
|
|
| |
Gamedata bugs are the gift that keeps on giving. This was making vgui
stuff fail in L4D2 because the other outer conditions would match first.
It's perhaps unfortunate that we have to remove short-circuiting in
cases where it would work fine, but who knows, maybe the compiler would
be smart enough to figure it out anyway.
At any rate it's necessary for correctness, so whatever.
|
| |
|
|
|
| |
The old GAMESPECIFIC mechanism had worked in practice but was
technically a little bit incorrect, oops.
|
| |
|
|
|
|
|
| |
The NE thing wasn't really correct, because it would match hypothetical
cases where OE and some other tag bit are both set. Now we simply use
!OE instead. The _GAMES_WITH inversion case is correct, because it
doesn't necessarily exclude OE from being included too.
|
| | |
|
| |
|
|
| |
Gamedata values contributed by Evan Lin. Thanks!
|
| |
|
|
|
|
|
| |
Not perfect, because if something fails extremely early, we won't see
it, but that'll never be fully solvable. This is good enough to see what
features succeed and fail in normal autoload conditions where we don't
expect the plugin to blow up immediately.
|
| |
|
|
|
| |
Not really sure what was going on here. This is just a workaround,
really, but it works well enough for the time being.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we're at it, come up with a way for certain gamedata matches to be
Windows-only. Somewhat reduces ifdef usage, although does not entirely
remove it of course.
Tested in HL2 2707. Haven't tested other HL2 builds, or Episode 1.
Doesn't seem to work in DMoMM yet either; not sure why.
A big list of stuff still to fix follows.
Hidden cvars are currently an issue. We still need to figure out what to
do with the flag bits because FCVAR_HIDDEN just doesn't exist in OE and
there's some other flag with the same value instead.
We also need to do something about the flag setting in fixes.c since
HIDDEN is again not a thing, and also DEVONLY is not a thing either.
When the plugin is autoloaded, all the initial log text gets eaten,
because there's some stupid crap we have to do to trick the engine into
displaying coloured text otherwise it just won't. Not even stuff from
Warning(). Very stupid, but Hayden already figured out a solution, so
that'll be done in another upcoming commit.
Apparently raw mouse input breaks the menu. We might need to bump up the
priority on making that hook only be active when there's no UI open -
something I wanted to do anyway due to the demo drive issues.
Big thanks to Hayden for doing a lot of the initial groundwork on this,
particularly the cvar registration stuff. He gets a copyright notice in
con_.c even though I ended up doing a lot of stuff differently because
quite a bit of his work is still in there.
Don't blame him for the self-modifying code though, that was my crazy
idea. Sorry, but, in my defence... Well, it works.
|
| | |
|
| | |
|
| |
|
|
| |
Very important.
|
| |
|
|
|
|
|
|
| |
This is more prep for OE, as it will allow us to change how the call is
forwarded for the other ABI (albeit in what looks like it'll be a fairly
involved way) without requiring a bunch of extra code at every call
site. It's maybe a little less efficient since the global has to be
loaded every time, but coloured logging isn't exactly a bottleneck.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this codebase is already extremely nonportable, I've decided to
relax the obsessive ifdef-else-error usage around all the extensions.
From now on, if there's no alternative to using an extension, we can
just use that extension. If it's possible to do something in a
relatively portable way, we can still try to do that in order to make
the code somewhat reusable, in contexts where that makes sense.
I also decided to use langext.h for naked functions and tail calls. If
that's used in another codebase build with a different compiler, those
just won't work, but that's fine. The benefit is really just that
there's less ceremony in places where those are used, because it's
likely there'll be a few more such places in the future, and it gets
annoying reading all the double-underscore stuff all over the place.
I still kind of want to do something about all the _WIN32 ifdefs too,
but I've realised that doing so will lead to almost nothing actually
being built on Linux. Then again, none of it currently runs on Linux so
I guess that's a moot point. Will worry about it later, anyway.
|
| |
|
|
|
|
|
| |
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.
|
Michael Smith
Hayden K
