1. Corewars-look-alike with Euphoria
Okay ladies and germs (sorry, just HAD to say that), I've officially
started making a Corewars-like game.
The structure of the VM (well, VM-ish thingamajig :) is a bit zany,
which was to be expected. After all, I'm the developer of the SECOND
only programming language (sort of) which has COME FROM implemented.
The 'virtual machine' is composed of a "Command Core" where all the code
for the competing programs is stored, a "Data Core" where the programs
can store data and a "Warrior Allocation Table", WAT (pronounced [huh]
or [eh]), which shows the owner of every sub-element (SEs are discussed
in the docs. If anyone wants 'em, drop me a line and I'll translate
them) and which SE's are active (also discussed in the docs)
What I need done is the VM itself :)
I've got the routines that load the warriors into the core after
initializing CC (commcore), DC (datacore) and WAT. All I'm lacking is
the functionality; the parser for the script et al. I'll probably be
forced to do them myself, but as I said, if you're even half interested
at looking what I have so far, hurl an e-mail at me, and I'll translate
the source's (one .e and one .ex) comments and the notes I've made.
For the sake of examples, here are a couple of things that I've written
with the script (just practising):
{
{
"MOV", "@0", "@1"
}
}
'Yer standard, dumb Imp. Copies itself forwards. Notice the nested
sequence structure (yes, the warrior files are normal euphoria
sequences)
{
{
"JMP", "@3", "@0"
},
{
"MOV", "@0", "@1"
},
{
"ACT", "@-1", "@0"
},
{
"MOV", "@0", "@1"
}
}
This is what I call an Imp Factory.
-> this symbol means that the command will be executed in the next cycle
> this means that the command was executed
>jmp @2 @0
mov @0 @-1
act @-1 @0
mov @0 @1
1. the pointer moves forwards by two
jmp @2 @0
mov @0 @-1
->act @-1 @0
mov @0 @1
2. The ACT-opcode activates the previous command AND itself
jmp @2 @0
->mov @0 @-1
>act @-1 @0
mov @0 @1
3. This starts the Imp Factory. An endless stream of Imps in generated
->mov @0 @-1
>mov @0 @-1
>act @-1 @0
->mov @0 @1
4.
->mov @0 @-1
>mov @0 @-1
>mov @0 @-1
>act @-1 @0
>mov @0 @1
->mov @0 @1
etc
This bastard might be hard to kill, but using an Imp-gate (haven't done
one yet :) and a NOP-carpet (not done either, but I have an idea how it
should work :) in the commcore would kill it. Or just let it smash its
ACT-command and use an imp-gate
well, enough of that.
So far I only have 3 addressing modes (not enough, more will be added):
CC-Relative @, DC-relative $ and CC A- or B-field relative #
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
