ilc.exe is emitting the sse instruction, xorps, with --instruction-set base

[FrankRay78]

I'm using ilc.exe with the following switches 'ilc --targetos windows --targetarch x86 --instruction-set base' and it sometimes emits the sse instruction 'xorps'.

Given there are specific instruction set switches for sse (sse, sse2, sse3, ssse3, sse4.1, sse4.2), I can't tell if '--instruction-set base' should be allowing the 'xorps' instruction. I've searched and can't find any documentation on this, apart from the command line help, 'ilc.exe --help'

What is the correct behaviour?

---

PS. The 'xorps' instruction isn't consistently emitted.

In the branch, Kernel-no-sse, the 'xorps' instruction isn't present when compiled. See kernel-working.elf

When I add a single, declared and initialised, but never used, private byte variable within the Console.cs struct, it does.

private byte foregroundColor = 0x0F;

The branch, Kernel-with-sse, demonstrates the 'xorps' instruction being emitted. See kernel-notworking.elf, address 0x00201006:

201006: 0f 57 e4 xorps %xmm4,%xmm4

[filipnavara]

Firstly, win-x86 is unsupported. There is an effort to enable it for .NET 9 but no usable preview shipped so far (daily builds may or may not work). Secondly, the baseline is SSE2. Any supported version of Windows already requires that as a baseline. Even if the JIT didn’t emit the SSE code the native libs are compiled with it, and so is the CRT support code in the system.

(I understand that you are supplying part of the native side yourself but it was never a supported scenario for ILC in the Windows context.)

(Side note: CoreCLR did historically support non-SSE2 machines, and so did RyuJIT. That’s where the instruction set flags come from.)

[tannergooding]

The support for pre-SSE2 hardware was removed several years back and there is no interest in adding it back. We consider at least SSE, SSE2, CMOV, and CPUID as part of our baseline requirements (there may be other minor ISAs I've forgotten as well).

SSE2 came out with the Pentium 4 around 2000 and is a baseline requirement of all x64 CPUs. MSVC, Clang, and GCC have all defaulted to using SSE2 on x86 (32-bit) targets for years. You have to go out of your way to target such hardware and even more out of your way to have such hardware to run on in the first place.

Even for the Linux kernel, they are looking at phasing out support for many old CPUs due to the cost of maintaining the code. They pulled i386 (1985) support back in v3.8 and are looking at dropping i486 (1989) and requiring Pentium or later in v6.1 (https://lore.kernel.org/lkml/CAHk-=wikUaRM5H_y1Bc+QyvGi40dKDL8fnCTyz7ECbwK7aHNPQ@mail.gmail.com/). While having i586 (1993) as a new baseline for Linux still wouldn't guarantee SSE (Pentium III in 1999) or SSE2 (Pentium 4 in 2000), any support for such hardware is rapidly depleting. Most Linux distros don't even ship 32-bit versions anymore, requiring you to build it yourself from scratch.

[jkotas]

BTW, the development of native AOT has been moved to dotnet/runtime repo (except for the LLVM backend - LLVM backend is still lives in this repo). https://github.com/dotnet/runtime/ is a better place to open issues related to native AOT.

[FrankRay78]

Thank you all for your responses, it's been really helpful and I appreciate your time.

It looks like I should set my ambitions higher and see about developing a 64-bit kernel / x64 AOT native compile instead.

Update - for anyone finding this thread via search engines etc, there is an accompanying discussion over at OS Dev, here: Including an unused variable corrupts the multiboot kernel