Game of Life

[CornedBee]

Um ... no.

If you do this is straight assembly, your biggest problem is probably the syntax difference. You'd have to code with gas on Win32 while testing.

But if you code to pthreads, there are pthreads implementation on top of Win32.

As for the GPU, well, good luck. OpenGL is cross-platform, so it might work. I'll have to look up my exact GPUs though.

[abachler]

Any reason why you want AT&T syntax? I was unde the impression that gcc uses intel syntax for inline assembly.

[Cactus_Hugger]

Any reason why you want AT&T syntax? I was unde the impression that gcc uses intel syntax for inline assembly.

AFAIK, gcc only supports AT&T syntax.

[brewbuck]

Any reason why you want AT&T syntax? I was unde the impression that gcc uses intel syntax for inline assembly.

GCC uses whatever syntax the assembler wants.

[CornedBee]

If your build system can convince gas to use Intel syntax, you're welcome to use it. I don't think it really supports it.

[robwhit]

Aparrently, .intel_syntax is an undocumented directive that is supported in versions 2.10 and later in gas.

http://www.osdev.org/wiki/GAS
http://www.google.com/search?q=.intel_syntax+gas

[arpsmack]

Do we have to display the grid every generation, or just display the final generation?

[CornedBee]

Only the final result is of interest. Otherwise, the contest would be about I/O speed.

[jEssYcAt]

Well, considering the expertise of others here who will enter I don't think my entry has a shot of winning, but I plan to enter it just the same (it's actually completed, but I want to tinker with it a bit and make it "pretty", add some bells and whistles and whatnot). I don't know enough about Assembly to get under the hood and tinker with my compiler's output effectively.

Your comment

However, I will give out bonus points for solutions that do not use fixed-size grids. I'll just have to think of a fair and balanced way of adding that in.

got me thinking, and I plan to make my entry capable of simulating a board with millions of live cells without requiring gigabytes of memory.

I am just wondering when you will post some test input/output files for us to tinker with. I'm pretty confident that my implementation is working properly, but it would be nice validation to run an input file and have my program produce the correct output for x generations. Thus far I've done that by hand with relatively small test patterns, but I'd love to throw a puffer train at it and have the output match a couple thousand generations of simulation.

[CornedBee]

You're right. Here are the reference files in steps of 500.

[CornedBee]

And the last two.

[jEssYcAt]

Woo hoo! My ouput matches at each stage, and it took only 15 seconds (counted outloud with "one thousand one, one thousand two" method) to run 3000 generations. =o)

Now I can figure out which bells and whistles I'm going to attach.

Thanks, CornedBee! Also, did you generate these or get them from somewhere? I did searches on Google but only ever found starting patterns.

[robwhit]

Implementations based on hashlife are forbidden, sorry. This advanced algorithm is so superior that it would be pointless to compare it against the other possibilities.

Does this mean that any 2D pattern matching over time is out?

How close are we talking about "based on" here?

[CornedBee]

Also, did you generate these or get them from somewhere?

These were supplied by the university. But they generated them themselves.

Does this mean that any 2D pattern matching over time is out?

The basic algorithm of hashlife is to identify larger patterns and predict their development. This is forbidden.

[brewbuck]

I hope people are still working on this.