Zero Runtime: Basic Operations and SIMD

[CaiB]

Hello,

I'm trying to build a simple DLL that does some math operations for use in C/other native applications, out of code I already have in a C# project. The default .NET 8 AOT compiler gets me to a 1.4 MB DLL, while bflat gets me to 944 KB with just --no-globalization. Since this is just math totalling under 1000 LOC, with no GC needed (allocations done once at init, never after), I was hoping that ideally bflat/the zero runtime would help me get this DLL to under 50KB.

However, when attempting to compile with --stdlib:zero, I get a ton of errors, many being about a few issues:

• error CS0103: The name 'MathF' does not exist in the current context (MathF.Min, MathF.Max, etc)
• error CS0103: The name 'Debug' does not exist in the current context (Debug.Assert, should become nops in release builds anyways)
• error CS0518: Predefined type 'System.Index' is not defined or imported (when indexing an array with [^1]
• error CS0518: Predefined type 'System.Runtime.CompilerServices.IsExternalInit' is not defined or imported (properties with {get; private init; })

As well as a ton of these since I've manually optimized my math to use x86 SIMD operations where possible:

• error CS0103: The name 'Avx2' does not exist in the current context
• error CS0103: The name 'Sse' does not exist in the current context
• error CS0246: The type or namespace name 'Vector256<>' could not be found (are you missing a using directive or an assembly reference?)
• error CS0246: The type or namespace name 'Vector128<>' could not be found (are you missing a using directive or an assembly reference?)

I mostly wanted to ask if these errors are expected, and implementing these (mostly basic) operations are outside the scope of Zero, or if there's something I'm doing wrong.

Thanks!

[CaiB]

Just saw #163, which means at the minimum MathF also is off the table.

I'm still curious if the SIMD operations could be implemented though, even if just a subset of the basic System.Runtime.Intrinsics.Vector128/Vector256 types (enough to construct, initialize to zero/a constant, load and store would be fine), and the intrinsics that directly map to instructions like found in System.Runtime.Intrinsics.X86.Avx2/Sse/etc. were available, that'd go a long way towards making tiny math-centric libraries possible.

I can probably figure out how to copy over MathF from regular dotnet and avoid using the rest of the things listed which are causing trouble.

[MichalStrehovsky]

My suggestion would be to try hacking with the zerolib yourself - https://github.com/bflattened/bflat/tree/master/src/zerolib has instructions how i do it - you can just stdlib:none and add whatever you need to zerolib by copying from dotnet/runtime (it's also a good learning experience on how things are implemented).

I don't think I'd go the way of adding much more to zerolib than there is now. It's extra work to keep that in sync with upstream. For your own projects you always have the option to just stick to a single version of bflat. But I'd need to carry over everything that was added to future versions and these things sometimes change.

[cyraid]

What would be awesome to see sometime (if it were at all possible), would be to start with a zero lib, and automatically detect features and include them as necessary. Would be the opposite of trimming.