Game of Life

[daydreamer]

Just curious: why did you feel compelled to move this into 64-bit land?

I'm interested in 64-bit and I've known about Conway's Life for a long time. People have been creating patterns on very large playing fields. That calls for the ability to zoom the display in and out, as some visual effects can only be seen from a macro view. The large amount of data means speed and compactness become important. My effort is just a tiny poke into this world.

I suppose I should make a UASM version. It will break MASM compatibility. But it would be cleaner.

Kudos for 64 bit version
I am interested in 128bit SIMD and MMX later SSE2 instructions are made for speedup image processing and if user has 4k screen ,option for use that kind of screen resolution and padd  instructions you can add together number of neighbouring pixels in parallel

[tenkey]

and you can use push & pop where needed:

If you know what you are doing 
Dangerous otherwise.

AFAICT it's only a real concern if you want to handle exceptions or pass exceptions back to C++ code. An interesting question is if UASM PROC args, USES, LOCALs, INVOKE, and RET properly work together--involving issues I had to consider when constructing STRUCTs for local (stack) data.

[sinsi]

If you ignore shadow/spill space, ML64 will correctly setup LOCAL variables, PROC args and USES via RBP.
You still need to spill the first 4 args if needed, though.

[tenkey]

An interesting question is if UASM PROC args, USES, LOCALs, INVOKE, and RET properly work together--involving issues I had to consider when constructing STRUCTs for local (stack) data.

The automatic generation of STACKBASE:RSP code is broken, so there will not be a UASM version of Life. I have some ideas for fixing it.

There is an almost MASM-compatible interface with STACKBASE:RBP (default), but that's not what I'm aiming for.