rec.games.corewar Google Group

Re: PMARS with Extension 2009 (pretty good beta) now available ! (Source code available too ! ;):))

2009-12-19T22:08:04Z

Source code now available too in three "flavors":
1. Windows zipfile
[link]
2. Windows rarfile
[link]
3. Uncompressed
[link]

The first extension 2009 warrior: (Skybuck's) CodeCyclingBomberV1 !!!!!!!!! :) =D=D=D

2009-12-19T21:55:59Z

Hello =D
I proudly present to you... the first extension 2009 warrior EVER !
YEAHAHAHAHAHAHAHAH =D
Bye,
Skybuck ;):
;redcode CodeCyclingBomberV1
;name CodeCyclingBomber
;author Skybuck Flying
;strategy Cycles the instruction.code of the bomb thrown into the core.
;version 1
;date 17 december 2009

PMARS with Extension 2009 (pretty good beta) now available !

2009-12-19T21:46:55Z

Hello,
Today I finished the first pretty good beta of PMARS (for Windows 95 and up)
with Extension 2009 !
The software can be downloaded at this link:
(server version available too)
[link]
So now you can start developing and testing warriors with extension 2009

Re: x86 might be ok for self-modifieing code as well...

2009-12-18T18:42:36Z

I have no problems whatsoever on Windows with
VirtualAlloc(heapstart, size, MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE));
or on Linux with
mmap(heapstart, size, PROT_EXEC|PROT_READ|PROT_WRITE , MAP_ANON|
MAP_PRIVATE, -1, 0));
Any JIT needs that, and programming languages with JITs come even from

Re: Redcode Extension 2009, Specification 1.00 now available ! (Followed after "Understanding redcode programs" introduction.)

2009-12-17T14:48:34Z

The PMARS (C programming language version) is coming along nicely ! ;) :)
I made the necessary changes to the C code so I can start implementing the
additional modifiers.
For now it was interesting to see that the compressed version is actually
twice as slow as the uncompressed version. (Also optimizing for size made it

Re: PMARS server version is probably going to be faster ! ;)

2009-12-17T10:39:57Z

Nope...
It seems the debug field is necessary even in the server version... probably
for parsing... that's kinda shamefull ! ;)
Maybe that can somehow be solved ! ;)
But not gonna try that now ! ;)
Later,
Skybuck.

PMARS server version is probably going to be faster ! ;)

2009-12-17T10:13:38Z

Hello,
I just made an interesting discovery...
The instruction/mem_struct contains a special field called:
FIELD_T debuginfo;
It's in global.h
FIELD_T is 1 byte long.
This field is probably only used for the debugger which is removed/disabled
for the server version.
By disabling this field for the server version the following ammount of

Re: x86 might be ok for self-modifieing code as well...

2009-12-17T10:06:17Z

It will if you ask it to do so. JITs depend on it.
Best regards
Piotr Wyderski

Re: Redcode Extension 2009, Specification 1.00 now available ! (Followed after "Understanding redcode programs" introduction.)

2009-12-16T19:44:59Z

Hi Skybuck,
can you please put the document in a prober layout?
Me: Euhm I don't think so... I kinda like it the way it is right now =D
It makes me shizzel de dizzel reading centered text over the complete
Me: LOL
assay... it would be more readable, if it is formated nicely by the
Me: Mhoaw... not really... just read it line-by-line... that's how it was

Re: Redcode Extension 2009, Specification 1.00 now available ! (Followed after "Understanding redcode programs" introduction.)

2009-12-16T17:57:23Z

Hi Skybuck,
can you please put the document in a prober layout?
It makes me shizzel de dizzel reading centered text over the complete
assay... it would be more readable, if it is formated nicely by the
author and please make use of the <pre> Tags or something like that to
show, which are code-examples ;)

Redcode Extension 2009, Specification 1.00 now available ! (Followed after "Understanding redcode programs" introduction.)

2009-12-16T04:00:54Z

Hello,
I just wrote a document containing two sections:
Section 1 of 2: "Understanding redcode programs" by Skybuck Flying.
Section 2 of 2: "Full Specification for Redcode Extension 2009" by Skybuck
Flying.
(Redcode Extension 2009, Specification 1.00 created on 16 december 2009 by
Skybuck Flying).

Re: x86 might be ok for self-modifieing code as well...

2009-12-16T00:06:19Z

Errr... VirtualAlloc with PAGE_EXECUTE_READWRITE?

Re: x86 might be ok for self-modifieing code as well...

2009-12-15T22:16:54Z

That's what I get for replying from memory, after not looking at
something for three years...
From:
[link]
MOD
00 [register indirect]
01 [reg + imm byte]
10 [reg + imm dword]
11 reg direct
The difference between "op r,m" and "op m,r" (source or dest from

Re: x86 might be ok for self-modifieing code as well...

2009-12-15T18:06:36Z

You can obviously turn use of the NX bit off. However writing software
which depends on security features of the OS being turned off rather
limits your potential audience for a delivered program.
What the Windows API says is allowable and what is actually implemented
by the hardware may of course be different. Indeed it may be possible

Re: x86 might be ok for self-modifieing code as well...

2009-12-15T13:48:52Z

That is funny because before AMD introduced the "NX" bit, you couldn't
even make a difference between "read" and "execute".
I believe that you can still disable the use of the "NX" bit in the
Windows kernel.
Casper