Never quite understood why bit depth and gamut are coupled. Surely you could just redefine where 0 and 255 are.

- I’m excited to see the compacting GC come into existence when it is finally ready.

- That’s probably why the stack alignment was spotty. I was able to get 8-byte alignment consistently, and the code in the arch-specific code looked ready for 16-byte alignment, but obviously is lacking a little. If I’m able to get some free-coding time I’ll take a look into it.

As for the NullPointerException, there may be a way to intercept the fault, and if it is a SIMD instruction with an address, and that address is not aligned, emit a NotAlignedException (new exception type) instead.

I look forward to seeing the development of Mono 2.8 as it progresses. Thanks again for looking in on this.

-Mono uses boehm gc, which doesn’t support allocating 16 bytes aligned memory unless we do it for all objects, which would waste quite some memory. It will be possible to lift this
restriction once mono moves to it’s new moving gc.

-Stack variables aren’t aligned simply because no one finished support for them. It would be great if you could help us with it.

Besides that, good point that Aligned Store operations should take [out] params instead of [ref].

Vector2ul.Zero is not really optimized at all. You can just use new Vector2ul () instead, which would do exactly what you want. It should be quite trivial to do it thou.

The NullPointerException is not the best thing in the world, it would be nice to change the runtime to raise something more appropriate. But, at the same time, it doesn’t cause your program to crash, so it’s not that bad after all.

I’ll try to get some of your suggestions on the 2.8 release of mono.

Please – if you have the time – keep on posting similar articles (and simd tutorials) as – like you said yourself – there’s very little to found in documentation/tutorials on using mono.simd

~ Filgood