| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Saves multiple kilobytes, somehow. Unlikely to make much of a
performance difference since it's mostly init/shutdown stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
This isn't useful to us at all, but might be useful to someone else.
I always try to write code for multiple compilers for this reason, even
if SST ultimately still requires Clang.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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!
|