1. More Core War
------ =_NextPart_000_01BEE8B9.E0F06FC0
Alright all,
Attatched is a zip file, containing my Core War code. It's rough,
but includes some documentation, and a few example programs. It
requires get.e and graphics.e to run. I'll begin cleaning it up,
and possibly working on a parser, eventually.
Rob, please don't post this to the contribution site yet; I want
to check things out and make sure I wouldn't be violating
someone's copyright with a full public release...
Rod
------ =_NextPart_000_01BEE8B9.E0F06FC0
2. Re: More Core War
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET>
Aug 18, 1999
-
Last edited Aug 19, 1999
------=_NextPart_000_0033_01BEE9C6.75868860
charset="iso-8859-1"
>Attatched is a zip file, containing my Core War code. It's rough,
>but includes some documentation, and a few example programs. It
>requires get.e and graphics.e to run. I'll begin cleaning it up,
>and possibly working on a parser, eventually.
>
>Rob, please don't post this to the contribution site yet; I want
>to check things out and make sure I wouldn't be violating
>someone's copyright with a full public release...
>
I've completed a few programs and a parser program that converts source to a
format the get() statement can handle.
The parser isn't fully tested, and there isn't enough documentatino in the
parser to call it 'documentation', and the programs were written before the
parser so the get() format may not coincide with the written out version...
But the programs are good to look at.. if you can make a program to defeat
all of them, I wanna take a look. :)
Just remember that everything was put together very hastily... :)
------=_NextPart_000_0033_01BEE9C6.75868860
name="Cwstuff.zip"
3. Re: More Core War
Robert Pilkington wrote:
>I've completed a few programs and a parser program that converts source to a
>format the get() statement can handle.
[...]
>But the programs are good to look at.. if you can make a program to defeat
>all of them, I wanna take a look. :)
Well, it's good to see such a positive response in so little
time! 
Your programs and analysis are good Robert, and your "compiler"
works fairly well, too. I haven't tried Buddy's yet, but I'll
get around to it. I've been testing out a larger program idea
of mine against Assault, Strike and a few of my own. So far,
both seem to be holding their own...
J E M wrote:
>Btw, Rod, a friend of mine (Martin, you there?) used an idea a while back
>about using routine_id(). He used constants for the instructions, then
>assigned
>the routine_id() of the routines to execute them. So to execute one,
>there's no
>endless if..then..else structures:
Buddy, I also originally had looked at a more "user-friendly"
type of "compiled" CoreScript, so that MOV, DAT, ADD, etc.
were routine IDs. But there were a couple of problems there;
first, there would be no guarantee of what the routine IDs
would be, so over new versions of CW, or of Euphoria, old
programs might become invalid. (However, that's not as much
of a problem now that code can be compiled.) The second
problem though, is that it would almost demand something
like
{MOV, DIRECT, DIRECT, 0, 1}
as a compiled instruction. That was what I was looking at
when I first visualized this, but I soon came to realize
that that would require major reworking of the MOV
instruction. 
Also, after checking out the KoTH site, I've realized my
variant of Core War is somewhat lacking. I knew the SPL
(split) instruction was used before, but I hadn't thought
it really necessary. What it does is allow multiple threads
of execution for one program, at the cost of slowing the
execution speed for each thread. I had purposely left that
out though, because not only was I lazy and in a hurry to
get something working, it seemed like a "cheap" feature.
My thinking was, by just splitting often enough (those more
familiar with CW may have heard of the "imp factory"), you
make sure you never lose. Sure, you slow your program down,
but I had thought that it would still make it impossible for
an opponent to kill each thread. Apparently, that isn't the
case, or it hasn't been causing problems for more advanced CW
implementations. As my variant *currently* stands, it seems
to force all winning programs to be tiny, quick-bombing
entities; not terribly exciting. SPL could definitely spice
that up (and PCT would help prevent abuse of it.) So how about
it... what do y'all think about implementing SPL?
Rod
4. Re: More Core War
CoreWars - YEOW!!!
Buddy and I had a really intense correspondence about that last summer, that
didn't quite get functioning software off the ground. You guys are making
really rapid progress - I'm still digesting your code. Burp.
I've lost my notes from last year. I think the thing that got me stuck was
the complications of the addressing modes. I've butted my head against
assembler type languages for years and years now and never made any
progress - and my attempt at corewars was no more successful
But I was also developing some ideas for displaying the evolution of the
game. The idea was to have the display broken into concentric rings, with
the outer ring being the present state of the core, and previous states
could be pushed further and further into the centre until they disappeared.
I'll see if I can hook that up to whatever Corewar system you guys get
together.
> J E M wrote:
> >Btw, Rod, a friend of mine (Martin, you there?) used an idea a while back
> >about using routine_id(). He used constants for the instructions, then
> >assigned
> >the routine_id() of the routines to execute them. So to execute one,
> >there's no
> >endless if..then..else structures:
>
> Buddy, I also originally had looked at a more "user-friendly"
> type of "compiled" CoreScript, so that MOV, DAT, ADD, etc.
> were routine IDs. But there were a couple of problems there;
> first, there would be no guarantee of what the routine IDs
> would be, so over new versions of CW, or of Euphoria, old
> programs might become invalid.
My recollection is that the routine ID's were dynamically set each time the
program was run so the actual values set would vary from run to run, but
still the constant (say) MOV would always point to the correct routine. But
I'll have to check.
Bye
Martin
5. Re: More Core War
[Martin] >You guys are making really rapid progress
Well, I think the reason I was able to get a compiler out so
fast was I really liked Rod's approach - it was simple.
I think we started with the wrong idea in mind: ICW88 compliance.
That introduced more complexity into the project than we could
handle. I certainly couldn't have written it as quickly without
the things I learned last summer tho :)
>My recollection is that the routine ID's were dynamically set each
>time the program was run so the actual values set would vary from
>run to run, but still the constant (say) MOV would always point to
>the correct routine. But I'll have to check.
Yeah, you're probably right; I've lost all my notes too <g>
The reason we can't use routine_id() here is that the compiled
warriors require static numbers. DAT's routine_id() might be
0 today, but change to 7 with the next update. In order for the
warriors' compiled code to work, the numbers have to stay the same.
It worked for us because we didn't try to compile the warriors into
an intermediate format (although we were toying with the idea, right?),
we just took the Redcode straight to the core.
I'm still trying to figure out how to implement labels in my compiler :)
>I was also developing some ideas for displaying the evolution of the
>game. I'll see if I can hook that up to whatever Corewar system you
>guys get together.
I can't wait to see your code Martin, it's probably gonna be awesome!
Adding on to an existing system is alot easier than writing one from
scratch, so it shouldn't take too long.
----->Buddy
budmeister1 at juno.com
6. Re: More Core War
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET>
Aug 21, 1999
-
Last edited Aug 22, 1999
>[Martin] >You guys are making really rapid progress
>
>Well, I think the reason I was able to get a compiler out so
>fast was I really liked Rod's approach - it was simple.
>I think we started with the wrong idea in mind: ICW88 compliance.
>That introduced more complexity into the project than we could
>handle. I certainly couldn't have written it as quickly without
>the things I learned last summer tho :)
I hope that the compliance is a planned feature.. Maybe once Llama is
finished, a port can be done and be as popular as pMARS... (I've been to
www.koth.org too many times since I learned the URL, I guess. :)
>I'm still trying to figure out how to implement labels in my compiler :)
I just finished support for labels today. I'll post a copy when I test it
some more..
Rod, support for SPL would be nice, as well as for the CMP function. (CMP
can be used for testing a fence around your program for bombing, as I was
reading in the first article on Core War from Koth.org...)
Any idea when a cleaned up version will be released? (Along with support for
a parser like mine or Buddy's.)
7. Re: More Core War
>I hope that the compliance is a planned feature.. Maybe once Llama is
>finished, a port can be done and be as popular as pMARS... (I've been
>to www.koth.org too many times since I learned the URL, I guess. :)
IMHO, I think we should either:
1. Support a *subset* of the standard, and try to keep it simple.
2. Not even bother with the standards.
I've been subscribed to the CoreWarrior (rec.games.corewar) mailing list
for over a year, and trust me on this one: full compliance with either
ICWS88 or ICWS94 is insane :) I think the reason Rod wrote a CoreWar
program
was to have fun with it, and the more complex we make it, the less fun
it'll
be.
As for pMARS, it's been around as long as CoreWar has, and it's here to
stay
(with its infinite complexities).
Again, IMHO, I think we should try to keep CoreScript as simple and easy
to
use as possible. The steeper the learning curve, the less people will
want to
play. Maybe we should even aim for _not_ conforming to the standards, and
let
the evolution of CoreScript take its course. Trying to make this as good
as
pMARS is a mistake [IMHO]. I think our real goal should be to make it fun
:)
>I just finished support for labels today. I'll post a copy when I test
>it some more..
I'm interested in your approach to labels. As an example, let's take some
code like this:
Start MOV 0, 1
ADD #1, Start
This should translate to:
MOV 0, 1
ADD #1, -1
Do you allow expressions in your CoreScript? Like:
Start MOV 0, 1
ADD #1, Start+5 <--- evaluates to 4
I'm not sure if mine will or not... what do you think Rod?
>Rod, support for SPL would be nice, as well as for the CMP function.
If SPL & CMP are added, that will max out the number of instructions he
can
have (unless he recodes so the opcode value is more than 1 digit). Right
now
he only has room for 2 opcodes left.
>Any idea when a cleaned up version will be released? (Along with
>support for a parser like mine or Buddy's.)
I think I'm going to wait until Rod gets his new version out
to update my compiler/parser. Who knows what kind of goodies he has for
us in this next version ;)
----->Buddy
budmeister1 at juno.com
8. Re: More Core War
Hello
I'm sorry for butting in.
snip
>I think the reason Rod wrote a CoreWar
>program
>was to have fun with it, and the more complex we make it, the less fun
>it'll
>be.
snip
>Again, IMHO, I think we should try to keep CoreScript as simple and easy
>to
>use as possible. The steeper the learning curve, the less people will
>want to
>play. Maybe we should even aim for _not_ conforming to the standards, and
>let
>the evolution of CoreScript take its course. Trying to make this as good
>as
>pMARS is a mistake [IMHO]. I think our real goal should be to make it fun
>:)
I'm an industrial electrician, and I work with equiptment that use small
computers called PLC's (Programmable Logic Controllers). And they use GUI
type programming language called Ladder Logic. It really is easy language
to learn once you get down the basics.
Input Output
|---] [-------------------------------------( )---|
Think of it like this, Input is a switch and Output as a light bulb, and
the line as wire. The vertical line on the left hot (5 volts, 12 volt, or
110 volts, whatever) and the vertical line on the right is Ground or
Neutral. The Inputs (generally called contacts) are always in the left
side, and ouput is always on the right side. Inputs and outputs are usually
single bits ON/OFF.
Input1 Input2 Output1
|---] [----] [------------------------------( )---|
This line simply states:
if Input1 AND Input2 are ON or TRUE then Output1 will turn ON.
Input1 Output1
|---] [----+--------------------------------( )---|
| Input2 |
|---] [----+
This line simply states:
if Input1 OR Input2 are ON or TRUE then Output1 will turn ON.
Input1 Output1
|---]\[-------------------------------------( )---|
"]\[" is the NOT operator. This line simply states:
if Input1 is NOT ON or TRUE then Output1 will turn ON.
You can combine these in an infinite number of ways to get whatever logic
result you want. This is to give you a small idea of the way ladder logic
works and if you all are interested, I'll show you how they handle math
and comparisons.
I just thought that using this would make Core Wars a little unique, and
fun for the new user.
Thanks
Paul Martin
P.S. I guess this might be a little late.
9. Re: More Core War
>>I hope that the compliance is a planned feature.. Maybe once Llama is
>>finished, a port can be done and be as popular as pMARS... (I've been
>>to www.koth.org too many times since I learned the URL, I guess. :)
>
>IMHO, I think we should either:
>
> 1. Support a *subset* of the standard, and try to keep it simple.
> 2. Not even bother with the standards.
>
>I've been subscribed to the CoreWarrior (rec.games.corewar) mailing list
>for over a year, and trust me on this one: full compliance with either
>ICWS88 or ICWS94 is insane :) I think the reason Rod wrote a CoreWar
>program was to have fun with it, and the more complex we make it, the less
>fun it'll be.
I was thinking ICWS'88 compatability (as the first 'standard' standard to
support), but not getting there anytime soon... Y'know, something to do down
the line.. Anyway, 'fun' sounds good too. :)
>As for pMARS, it's been around as long as CoreWar has, and it's here to
>stay (with its infinite complexities).
I figured a graphical Llama version (once Llama is ready) would be cool, as
it'd be able to run on anything Llama can run on. Of course, it'll be a
while until that happens... (It'd definetally be more user-friendly than a
command-line version that makes you want to code a shell like PSHELL for it.
:)
>>I just finished support for labels today. I'll post a copy when I test
>>it some more..
>
>I'm interested in your approach to labels. As an example, let's take some
>code like this:
>
>Start MOV 0, 1
> ADD #1, Start
>
>This should translate to:
>
>MOV 0, 1
>ADD #1, -1
Yep, that's what happens... I'll explain my method at the end of this
e-mail.
>Do you allow expressions in your CoreScript? Like:
>
>Start MOV 0, 1
> ADD #1, Start+5 <--- evaluates to 4
>
>
>I'm not sure if mine will or not... what do you think Rod?
I see some areas where that would help. It doesn't support it yet, I'm going
to look at some expression evaluators written in Euphoria.
>>Rod, support for SPL would be nice, as well as for the CMP function.
>
>If SPL & CMP are added, that will max out the number of instructions he
>can have (unless he recodes so the opcode value is more than 1 digit).
Right
>now he only has room for 2 opcodes left.
Well CMP was in the original Core War. A SLT would be helpful, as well. That
way, a program can do better counters, and check if areas in code have been
damaged. (A JZ is easy to trick, just bomb with 1's or 34's or whatever
instead of 0's)
>>Any idea when a cleaned up version will be released? (Along with
>>support for a parser like mine or Buddy's.)
>
>I think I'm going to wait until Rod gets his new version out
>to update my compiler/parser. Who knows what kind of goodies he has for
>us in this next version ;)
I'll probably wait until the new version is out before I clean up my
version.
Ok, on to label support..
I looked at how pMARS handles labels. Here's how they are handled:
hi there i am a jmp hi
Is treated as
hi JMP hi
or
JMP 0
Basically, the first 'word' is the label if it isn't an instruction. So,
here's what I do:
I scan all the lines. If the first word of the line isn't an instruction,
and it fits the label rules (starts with a letter, rest is alphanumeric)
then I add it to the list labels. If a colon is found at the end of a label,
it is removed before it is put in the list. (Since colons are optional in
ending labels and are never used in referencing a label.)
Labels are stored in a sequence, each element containing {sequence label,
integer line}.
Once all the labels have been found, I go through the list again to convert
each parsed line (the first time through I break them up into each 'word')
into the atom format for CoreWars to read. While doing this, if a label is
found, I replace it with the number it should be (by doing a
labels[thislabel][2] - currentline).
After the labels are converted, I could use someone's expression evaluater
to evaluate, umm.. any expressions. :) I haven't plugged this in yet,
though.
Currently, if you put in something like:
A few too many labels MOV 0, 1
It is treated the same as if you put in:
a: DAT 0, 1
or
a DAT 1
Since the instruction parser expects the instruction to be first, and the
label finder removes the label from the line when it finds a label. (And
'few' isn't a valid instruction.) (All labels are converted to lowercase
during parsing.)
I don't know if I should 'fix' this or not. :)
10. Re: More Core War
Hi
When I got Rod's program up and running, I nearly abandoned my display
project. because his was simple and easy to understand and kind of nice. But
I decided to try it out anyway.
Well, I've been working on the display routine for Corewars for a few days
now. The joke's on me - it won't fit! I shoulda understood the code that you
guys were writing better before I started. Duh.
I assumed that when a 10000 location memory core was equivalent to 10000
bytes. Not so! The memory core has room for 10000 instructions, but each
instruction has at least 5 bytes, so the core is really 50000 bytes
addressable in 5 byte chunks.
Now all of the stuff translating the warrior programs into those lists of
huge numbers makes sense.
It makes sense, but personally, I don't think it's a good idea. I also don't
think it would be very hard to modify. But first, let me say why I don't
think this is a good way to go.
a) It gets too far away from the Corewars that the rest of the world plays.
The warriors in the Euphoria corewars would behave differently than the same
warriors in the real corewars, because the virtual machines are not
equivalent. In the present version, bombing memory location means bombing a
whole instruction. This is quite different from just bombing a byte of an
instruction, which is what I understand happens in real corewars.
b) There is quite a bit of overhead involved in translating the big numbers
into instructions, and moving them around. This isn't so much of a run time
problem with the program as it is, because it runs in a blink anyway. But if
one wants to do anything else with the data in the core (like use it for a
display), then the overhead of extracting that data really slows things
down.
c) Besides getting away from corewars, this virtual machine gets away from
being like a computer too - it's got a whole architecture of it's own, based
on instructions rather than bytes. One of the things I liked about corewars
was getting into the innards of a virtual CPU, to see how computers worked
at that level.
I'm with Buddy about having fun with this thing. There's no need to build
the whole standard corewars right off the bat - let's get something up and
running and start fooling around with it even if it's stripped down. Last
year, Buddy and I got bogged down in pMARS, among other things. Buddy's
advice about staying out of that quagmire is from hard experience. I'm
amazed, Rod, at the way you just stepped around the whole thing.
But I suggest, at this early stage, moving to a byte oriented core memory. I
don't think this would be so hard. Basically, instead of creating a big
number from the source, create a sequence of bytes that would be poked into
the core memory. Then, instead of reading the bignumber from the core and
translating it into instructions, modes and data, just extract that
information directly from the core.
No big deal - this is all just fun anyway - but I just thought I'd throw in
my two cents worth.
Bye
Martin
----- Original Message -----
From: J E M <budmeister1 at JUNO.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, August 22, 1999 6:01 AM
Subject: Re: More Core War
> >I hope that the compliance is a planned feature.. Maybe once Llama is
> >finished, a port can be done and be as popular as pMARS... (I've been
> >to www.koth.org too many times since I learned the URL, I guess. :)
>
> IMHO, I think we should either:
>
> 1. Support a *subset* of the standard, and try to keep it simple.
> 2. Not even bother with the standards.
>
> I've been subscribed to the CoreWarrior (rec.games.corewar) mailing list
> for over a year, and trust me on this one: full compliance with either
> ICWS88 or ICWS94 is insane :) I think the reason Rod wrote a CoreWar
> program
> was to have fun with it, and the more complex we make it, the less fun
> it'll
> be.
>
> As for pMARS, it's been around as long as CoreWar has, and it's here to
> stay
> (with its infinite complexities).
>
> Again, IMHO, I think we should try to keep CoreScript as simple and easy
> to
> use as possible. The steeper the learning curve, the less people will
> want to
> play. Maybe we should even aim for _not_ conforming to the standards, and
> let
> the evolution of CoreScript take its course. Trying to make this as good
> as
> pMARS is a mistake [IMHO]. I think our real goal should be to make it fun
> :)
>
>
> >I just finished support for labels today. I'll post a copy when I test
> >it some more..
>
> I'm interested in your approach to labels. As an example, let's take some
> code like this:
>
> Start MOV 0, 1
> ADD #1, Start
>
> This should translate to:
>
> MOV 0, 1
> ADD #1, -1
>
> Do you allow expressions in your CoreScript? Like:
>
> Start MOV 0, 1
> ADD #1, Start+5 <--- evaluates to 4
>
>
> I'm not sure if mine will or not... what do you think Rod?
>
>
> >Rod, support for SPL would be nice, as well as for the CMP function.
>
> If SPL & CMP are added, that will max out the number of instructions he
> can
> have (unless he recodes so the opcode value is more than 1 digit). Right
> now
> he only has room for 2 opcodes left.
>
>
> >Any idea when a cleaned up version will be released? (Along with
> >support for a parser like mine or Buddy's.)
>
> I think I'm going to wait until Rod gets his new version out
> to update my compiler/parser. Who knows what kind of goodies he has for
> us in this next version ;)
>
>
> ----->Buddy
> budmeister1 at juno.com
>
11. Re: More Core War
simulat wrote:
>a) It gets too far away from the Corewars that the rest of the world plays.
>The warriors in the Euphoria corewars would behave differently than the same
>warriors in the real corewars, because the virtual machines are not
>equivalent. In the present version, bombing memory location means bombing a
>whole instruction. This is quite different from just bombing a byte of an
>instruction, which is what I understand happens in real corewars.
Hmmm, I had assumed it was
1 full instruction = 1 memory address
Mostly, this was because that was how the articles I read
described it. The info I saw www.koth.org didn't specify,
but it seemed similar. I'll have to check into that; you
might be right, but then I'd have to figure how they got
the Imp program (MOV 0 1) running.
But then, maybe that was just the original incarnations.
Ah well, we'll see how it goes.
>I'm with Buddy about having fun with this thing. There's no need to build
>the whole standard corewars right off the bat - let's get something up and
>running and start fooling around with it even if it's stripped down. Last
>year, Buddy and I got bogged down in pMARS, among other things. Buddy's
>advice about staying out of that quagmire is from hard experience. I'm
>amazed, Rod, at the way you just stepped around the whole thing.
Blame that on trying to create a working program from an
incomplete, skeletal description! I guess simpler truly
IS better.
Rod
P.S. - Since Core War is "arguably public domain", the next
release will be made available on the Eu site as well.
12. Re: More Core War
> a) It gets too far away from the Corewars that the rest of the world
plays.
> The warriors in the Euphoria corewars would behave differently than the
> same warriors in the real corewars, because the virtual machines are not
> equivalent. In the present version, bombing memory location means bombing
> a whole instruction. This is quite different from just bombing a byte of
an
> instruction, which is what I understand happens in real corewars.
Actually, the behavior of Rod's Core Wars is the same as in other Core War
MARS programs.
The only differences between Rod's and the other MARSes, are these:
MOV #5, 1
MOV 5, 0
CoreScript = Move DAT #0, #5 to the second statement
RedCode = Move #5 to the B-field (the 0) of the second statement (I think)
JMP 5
CoreScript = JMP #0, 5
Redcode = JMP #5, #0
(Redcode uses the A-field for JMP, while CoreScript uses the B-field)
A DAT bomb bombs instructions, not bytes so that the DAT statement is
executed, which terminates the program (or process, once SPL is
implimented).
The basic idea in Redcode ("real Core War") and CoreScript is the same, but
the handling of the instructions is a little different. In both languages,
the Imp works the same way: (Although a compiler/parser will be needed to
convert the code for CoreScript)
MOV 0, 1
It moves (well, copies) the instruction at 0 to one instruction ahead of it.
Then the program moves to the next instruction in the array. Which happens
to be exactly where the previous command had copied to. So the Core looks
like this:
MOV 0, 1
MOV 0, 1 <- Current statement (about to be executed)
DAT 0, 0 < - Next statement
When the current statement is executed, the DAT (or whatever happens to be
next) is overwritten with the MOV.
> c) Besides getting away from corewars, this virtual machine gets away from
> being like a computer too - it's got a whole architecture of it's own,
based
> on instructions rather than bytes. One of the things I liked about
corewars
> was getting into the innards of a virtual CPU, to see how computers worked
> at that level.
The virtual computer in Core War (MARS (Memory Array Redcode Simulator) is
described in the Core War FAQ at www.koth.org as an array of instructions.
(Not as an array of bytes.) So they are mostly the same. (In fact, with the
progress made so far, it doesn't seem like it'd be too much work to get
compliance with Redcode '88... I could be wrong though, but it just seems a
few extra instructions and some modifying of a couple instructions should do
it.)
Also, somewhere that I read stated that if Redcode and MARS worked like a
true virtual computer, then it would be so complex that very few people
would be able to write successful programs, much less understand them.
I just thought I'd toss my two DAT bombs in. :)
