| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Pretty hacky for now, but not the worst thing in the world. Can always
be tidied up later.
|
| |
|
|
|
| |
The old GAMESPECIFIC mechanism had worked in practice but was
technically a little bit incorrect, oops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This doesn't allow us to support OE in and of itself but is part of the
groundwork necessary to do so in the future.
|
| |
|
|
|
| |
I think this might actually be the last of the gluegen regressions now,
for real, maybe, perhaps.
|
| |
|
|
| |
I inverted the condition, d'oh!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically when building in debug mode, we now:
* Display all features on load, including skipped and internal ones,
sorted by internal name instead of display name.
* Print the names of all matched gametype tags after the feature list.
* Add an sst_dbg_getcmdcb command to get the address of a command
callback for quick breakpoint insertion or Ghidra lookup.
* Add an sst_dbg_sendtables command to dump out the full ServerClass
tree to help get names for entprops.txt. Note: this output is very
long so you'll likely need to log console output to a file to be able
to read it all.
There's a bunch of developer experience and debug help stuff I want to
get done eventually. This is just a very small piece, but it's a start.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
In the future we can also consider moving to {} instead of {0} for
initialisers, but my old Clang (16) doesn't support this, so it might be
wise to wait longer on that one so people don't need too bleeding-edge
of a compiler just to build this thing.
|
|
|
Also switch to somewhat proper C23 flags while we're at it.
This is a huge change. It took me forever, in between being really busy.
Sorry about that. But the good news is I'm now free to start integrating
the various patches that have accumulated since last release. Well, at
least in between still being really busy. Gotta manage expectations.
The main benefit of introducing GAMESPECIFIC() is that features
that don't apply to a particular game no longer show up *at all*, and
less time is wasted on init. It also enables a cool optimisation wherein
unnecessary REQUIRE_GAMEDATA() checks can elided at compile time
whenever the gamedata is known up-front to always exist in supported
games.
The DEF_FEAT_CVAR macro family meanwhile makes it easier to manage the
lifecycle of cvars/ccmds, with less manual registering, unhiding and
such.
Originally I was going to try and just hack these features into the
existing codegen abomination, but it just got too terrible. This rewrite
should make it easier to continue tweaking codegen behaviour in future.
It also has slightly better error messages.
|
Michael Smith
