For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism.
Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.
Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.)
In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.)
(This is why I prefer console gaming or "simple" games that don't tax the hardware.)
I appreciate there will parts of a game that have hand rolled assembly, but even those have problems when x86 move forward. In the near future SIMD instructions will double their widths and todays fast code using them will be old.
C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.
dagmx · · focus · HN ↗
Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.
MiroslavPokorny · · focus · HN ↗
THen they wouldnt require any emulator for any new compiles.
gwbas1c · · focus · HN ↗
Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.)
In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.)
(This is why I prefer console gaming or "simple" games that don't tax the hardware.)
MiroslavPokorny · · focus · HN ↗
C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.