Places them in RO where they can't be modified.
While we're in the area, we can use an alias to prevent duplicated array
types, and also add a static assert to ensure the arrays are always the
same size.
This allows us to avoid needing to bounds check several accesses in a
row that we know will always be successful.
When running the cpuid application (http://www.etallen.com/cpuid.html) I noticed
that we were returning some garbage data here.
After initially implementing support for leaf functions, it still didn't resolve the issue.
So I had to fix those in the x86-64 JIT.
I then went through and solved more issues with the function results.
- We now return a more sane CPU family that is near the feature set we support
- APICID now understands how to fill out the data correctly depending on emulated core counts
- Disabled some CPU features that we don't actually support
- Found two more cache functions that we weren't populating
- Filled with generic data cache size data
- Only thing that matters is that we ensure that cacheline size is reported as 64bytes
- L1D: 32KB, L1I: 32KB, L2: 512KB, L3: 8MB claimed for caches
- Implemented Leafs for functions
- 7h - Only has leaf 0
- Dh - Extended CPU features support
- Another register that lets you claim support for x87, SSE, and AVX
- Leaf 1 & 2 has some additional data
- 4h & 8000'0001Dh - Extended cache properties
- Almost the same as each other. One reports slightly less data though
After FEX has forked, there aren't any other threads in the process but their stacks remain.
We need to have some book keeping in place to have the stack ranges available to clean up
after fork.
We now keep both live stacks and dead stacks in a dequeue and on fork we will walk both to
clean up all stack objects that aren't our current thread.
rsi is a SSA argument, so we need to make sure to move the leaf argument first.
the leaf argument was getting corrupted when moving to the ABI.
Will be necessary once CPUID supports leafs
Passing in the string directly through the format string input can
unintentionally cause the output string to be interpreted as a format
string.
We can specify a separate format string to ensure it always prints
without any potential mangling.
<iostream> injects a static constructor in translation units that
include it, even if its facilities aren't used.
We can make use of <sstream> to avoid needing to execute those on
startup.
No specializations modify this, and even if they did, it would be a
little confusing to statefully modify the string this way.
Instead, we can make it read-only.
When floats and doubles were converting to integers we weren't doing the correct transformation.
AArch64 provides direct ops for all four of the op types. So lets use them
- f32 -> int64
- f32 -> int32
- f64 -> int64
- f64 -> int32
Doesn't fully fix the case of overflow for AArch64 since overflow behaviour is different.
x86 returns 0x8000'0000 or 0x8000'0000'0000'0000 while AArch64 saturates to the maximum signed
integers. Can't work around that without checking overflow flags.
This does solve the typical case though.
Fixes audio problems in all FMod games.
Ryan Houdek