Game of Life

[CornedBee]

Just under a month until the deadline. Please send your submissions to sebastian DOT redl AT getdesigned DOT at. It should be a single archive (zip, tgz, tbz, rar, 7z, I don't really care which).

[jEssYcAt]

Yep, brewbuck, I'm working on it too. I have a working version but I'm trying to improve on it before I submit it.

[abachler]

Originally Posted by brewbuck

I hope people are still working on this.

I never got a definative answer on the inline assembly.

I don't code for linux, so I probably don't have time to port a solution to it at this point. Any chance you can expand it to include win32?

[brewbuck]

Originally Posted by abachler

I never got a definative answer on the inline assembly.

I don't code for linux, so I probably don't have time to port a solution to it at this point. Any chance you can expand it to include win32?

If you write your assembly stuff in actual .asm source files, you could use NASM to assemble it, which can target both platforms. But inline assembly seems out, unless you learn the AT&T syntax, which honestly, is not that big a deal.

[abachler]

My intention is to write it in Visual Studio, so I guess Im out.

[mike_g]

Ok well I had a go at knocking up a quick version. Me being me I ignored the rules and made something with a graphical representation; the thought of staring at a list of co-ordinates trying to figure out what was going on would stretch my attention span a little too far. I couldent be bothered with lists either so its all done on, and limited to, a 2d array. Its very slow; O to the something horrible.

If anyone else finishes this youre guaranteed to beat me

I attached the source; it requires SDL. I'm not completely sure If I got it right. My little automatons dont seem to behave very interestingly off a random generated grid. Oh well.

[CornedBee]

I still fail to see how you can get an inline assembly version working reliably in both 32-bit and 64-bit environment (a requirement). In fact, Visual Studio does not allow inline assembly for 64-bit targets.

Thanks, mike. I'll try to give you some feedback over the weekend.

[brewbuck]

Originally Posted by CornedBee

I still fail to see how you can get an inline assembly version working reliably in both 32-bit and 64-bit environment (a requirement). In fact, Visual Studio does not allow inline assembly for 64-bit targets.

I haven't programmed in assembler on the AMD64 platform but I was under the impression that the 32-bit instruction set is all still available. Wrong?

[CornedBee]

Not wrong, but just because the instructions are available, doesn't mean you can use all code without changes.

For example, to completely dereference a double pointer, in 32 bits you do this:

MOV eax, DWORD PTR[somevar] ; Load variable
MOV eax, DWORD PTR[eax] ; Dereference once
MOV eax, DWORD PTR[eax] ; Dereference twice

In 64 bits you do this (guessing a bit here - do the 64-bit GPRs have a g or an r prefix?):

MOV gax, QWORD PTR[somevar] ; Load variable
MOV gax, QWORD PTR[gax] ; Dereference once
MOV eax, DWORD PTR[gax] ; Dereference twice (get at a 32-bit int)

In AT&T syntax, it's yet more complicated, because the operand size is in the instruction mnemonic. So instead of movl you have to write movq.

[abachler]

You can use inline assembly under VS 2005 and 2008 and it will compile for an x86 target, btu if you try to compile it for an x64 target , then it throws errors. Yeah lots of developers are ........ed at MS for that one, it basically makes it 10 times harder to write drivers, since now all the hardware companies have to buy additional products and convert all their existing code.

Sorry , didn't mean to derail your thread, lets get back on topic now.

[brewbuck]

Originally Posted by abachler

Sorry , didn't mean to derail your thread, lets get back on topic now.

You could always compete unofficially... I'm interested to see what you come up with.

[brewbuck]

Originally Posted by mike_g

My little automatons dont seem to behave very interestingly off a random generated grid. Oh well.

I think you're getting uninteresting results because you're not using the right rules:

                Uint8 u = (y > 0)? cells[flip][x][y-1]: 0;		
		Uint8 d = (y < Y_CELL-1)? cells[flip][x][y+1]: 0;
		Uint8 l = (x > 0)? cells[flip][x-1][y]: 0;
		Uint8 r = (x < X_CELL-1)? cells[flip][x+1][y]: 0;	

		switch(u+d+r+l)

You're only looking at the four neighbors above, below, left and right. The actual rules require you to examine the four diagonal neighbors as well. Add that, and I bet things get a lot more interesting.

[brewbuck]

Will you be analyzing memory usage of the submissions? It might be interesting data.

[jEssYcAt]

As long as there are no penalties for horrible abuse of memory... You did say you have 8GB of Ram, right?

[CornedBee]

I have one Gig on both test machines

I can analyze the usage, but I won't count it. My experience with our own program is that memory usage is its own speed penalty in CPU-bound applications. Basically, our performance went down drastically when the data got too large to fit into the L2 cache. And God help you if you start swapping.