FEXCore: Moves CodeEmitter to own module

[Sonicadvance1]

The frontend needs to have a microJIT for BPF/seccomp. It can't use the CodeEmitter from FEXCore in its current state.

• Removes the vixl dependency from the CodeEmitter
  • Only vixl uses were its Float16 class. Replaced with a custom implementation
  • And IsImmLogical, which was added to its own header with vixl's license maintained. Reimplementing the logic is hard.
• Moves it to its own module
• Renames the namespace

No functional change

[lioncash]

Seems like this ifdef and fallback can be replaced with std::countl_zero from the <bit> header

[Sonicadvance1]

These two helpers are directly pulled from vixl. Didn't want to mess with them especially since they have some prickly behaviours like passing in a uint8_t but casting to different widths.

In-fact everything in this particular file is from vixl with as little changes as possible.

[lioncash]

std::has_single_bit

[neobrain]

Why doesn't this live in its own module? FHU makes sense for things that heavily inter-depend on each other and that are used virtually everywhere, but this is a fairly isolated piece of code.

[Sonicadvance1]

Why doesn't this live in its own module? FHU makes sense for things that heavily inter-depend on each other and that are used virtually everywhere, but this is a fairly isolated piece of code.

Moved to its own module.

[neobrain]

Looks fine to me in the grand scheme now that there's a dedicated CMake target.

Only vixl uses were its Float16 class. Replaced with a custom implementation

Is there an upside to this other than making the dependency graph simpler (without removing the use of vixl elsewhere)? The new class has no unit tests, so its upsides must be weighed against this added risk and the additional time required for the more careful review.

[Sonicadvance1]

Looks fine to me in the grand scheme now that there's a dedicated CMake target.

Only vixl uses were its Float16 class. Replaced with a custom implementation

Is there an upside to this other than making the dependency graph simpler (without removing the use of vixl elsewhere)? The new class has no unit tests, so its upsides must be weighed against this added risk and the additional time required for the more careful review.

An upside is that the vixl dependency isn't leaked to the frontend.

[neobrain]

An upside is that the vixl dependency isn't leaked to the frontend.

This could instead be achieved by hiding the definition of Float16 in a private cpp file. We can then make vixl a PRIVATE CMake dependency, such that its include directories don't get propagated to the frontend.

[Sonicadvance1]

To what end? This is the easiest route.

[neobrain]

To what end? This is the easiest route.

The PR replaces battle-proven code with a custom reimplementation of the same interface. Continuing to use vixl avoids risks associated with that, though I'd be happy to instead see tests for the new Float16 code as well.

[Sonicadvance1]

At this point I might as well as just delete all Float16 references since we don't even use it.

[neobrain]

At this point I might as well as just delete all Float16 references since we don't even use it.

I didn't know the code using Float16 wasn't hit. If it can just be dropped, that's even better.

[Sonicadvance1]

At this point I might as well as just delete all Float16 references since we don't even use it.

I didn't know the code using Float16 wasn't hit. If it can just be dropped, that's even better.

Deleted.