1. CoreWars issues
Well, it seems my last message was a bit late (I'm on digest), so here's
a
few thoughts on the ongoing CoreWars saga:
[Standards]
Rod, I'm glad you decided to blow off the standards. Martin & I did have
a heck of a time trying to figure em out :)
[Compilers]
I'm also curious as to why you decided _not_ to integrate a compiler into
CW. A few reasons come to mind, but also a few problems, especially with
one comment you made:
>as long as your compiler spits out a compatible sequence of
>atoms, it'll be valid for Core War to load. That way, you
>can allow/disallow labels, expressions, etc.
Unless every compiler has the same capabilities, exchanging CoreScript
with others might be a problem :)
One way to solve this is everytime you come out with a new version Rod,
release a specs document that describes all the guts of your program.
Then compiler authors could update their compilers to conform to the
specs.
That way *all* compilers will support a minimum of instructions and
features,
and then have any extensions their authors want.
Every compiler outputting the same stuff isn't really a good common
denominator;
if it's not common at the source level, then people may start renaming
instructions,
and make other changes to the language itself, which will confuse any
traded code even worse. We don't want their to be a zillion different
dialects of CoreScript ;)
[Bytes vs Bits?]
Martin, I'm not sure what [any of us] mean by a btye, but here's my
definition:
12099960044 - this is not a byte, this is a complete instruction
4 - this *is* a byte, a part of the instruction
Every full instruction is 11 bytes long.
Here's the breakdown:
opcode: 1 byte (0-9)
1st operand mode: 1 byte (0-2)
2nd operand mode: 1 byte (0-2)
1st operand: 4 bytes (0000-9999)
2nd operand: 4 bytes (0000-9999)
Probably not the best naming convention, but oh well :)
A feature my CWC prototype includes is 2-byte opcodes. This overcomes the
10 opcode limit imposed by having it as 1 byte. So the instruction:
12099960044 (1-2-0-9996-0044) -- 11 bytes long
using 2 byte opcodes would translate to:
012099960044 (01-2-0-9996-0044) -- 12 bytes long
Of course, in order for it to work with Rod's CW he'll have to code
support for it into his math routines. My prototype compiler still
handles
1 byte opcodes (by default); to compile to 2-byte you use a commandline
flag.
Maybe Rod can handle 2-byte using a flag too?
>I assumed that 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.
I can see where you're coming from on this one...
12099960044 -- 11 bits = 1 byte
4 -- 1 bit = 1/11 byte
Maybe we should make a standard way of referring to compiled data? I
would
prefer [my interpretation of?] Martin's method.
I know the feeling Martin: from looking at Rod's code, I first thought
that
each bit of an instruction was a sequence element. After I ran through it
with
trace on, I realized that each _byte_ (full instruction) occupied a
sequence element. Sometimes it's hard to figure out how internal data is
stored just by looking at the
code :)
[Instruction Storage In-Core]
>personally, I don't think it's a good idea (storing a complete
instruction):
>
> a) It gets too far away from the Corewars that the rest of the world
plays.
> b) There is quite a bit of overhead involved in translating the big
numbers
> into instructions, and moving them around... for a display.
> c) Besides getting away from corewars, this virtual machine gets away
from
> being like a computer too.
Well, sofar there's two ways to do it:
1. Store each bit of an instruction in one sequence element. Basically a
full
instruction is 11 elements long ( or CORE[FirstBit..FirstBit+11] ).
Pros:
There's no need for any parsing functions to separate the different
bits.
Cons:
The Core sequence gets 11x larger, possibly causing slowdowns.
2. Store each full instruction in one sequence element (the current
method).
Pros:
Keeps the Core down to a decent size, and init'ing the Core to
CORESIZE
only requires repeat(0, CORESIZE) and not repeat(0, CORESIZE * 11)
(not that it matters much :)
Cons:
Requires a routine to do bit munging before operating on an
instruction,
possibly causing slowdowns (like Martin mentioned).
Personally, I favor the 2nd method, because although it does need some
intermediate parsing of the numbers, it takes up less space overall, and
what
would you rather have: sequence size overhead or a little routine
overhead?
The original idea of CoreWars was to act like an abstracted computer
system,
but since we've gone so far from the norm anyway, why not stay in that
direction?
Thus endeth my comments for today,
----->Buddy
budmeister1 at juno.com
2. Re: CoreWars issues
J E M wrote:
>>as long as your compiler spits out a compatible sequence of
>>atoms, it'll be valid for Core War to load. That way, you
>>can allow/disallow labels, expressions, etc.
>
>Unless every compiler has the same capabilities, exchanging CoreScript
>with others might be a problem :)
Yes, that's true. But I didn't feel that was a terribly big
concern. I wouldn't imagine there would be much difficulty in
translation between forms, except for some odd features. If
anything I think they'll tend to be fairly similar. That's not
to say I still wouldn't suggest a standard, or wind up
recommending one specific compiler, or even eventually changing
my mind and integrating something. But I just don't think it
would be best for me to deal with that right now.
>One way to solve this is everytime you come out with a new version Rod,
>release a specs document that describes all the guts of your program.
>Then compiler authors could update their compilers to conform to the
>specs.
>That way *all* compilers will support a minimum of instructions and
>features,
>and then have any extensions their authors want.
That sounds like a good idea. Possibly even a suggested spec
for the compilers themselves.
>Every compiler outputting the same stuff isn't really a good common
>denominator;
>if it's not common at the source level, then people may start renaming
>instructions,
>and make other changes to the language itself, which will confuse any
>traded code even worse. We don't want their to be a zillion different
>dialects of CoreScript ;)
Mmm, I don't know. People could get weird with this, but at
their own detriment; if they want to use 'PROTECT' instead of
'PCT' in their own code, fine, but they better not expect me
to start using any odd varients in the documentation or
example programs! 
That'll be a good rule of thumb: a good compiler can at least
compile the example programs that come with the game.
[Bits vs. Bytes]
This is interesting, but aside from internal mechanics, it's not
really that important. Considering we're using Euphoria, I find
it MUCH easier just to think of each full instruction as an
individual atom, and each part of the instruction as a "slice"
of that atom (when visually represented:
curr_atom = 12200050008
curr_instr = sprintf ("%d", curr_atom) -- "12200050008"
instr_code = curr_instr[1] -- "1"
mode_of-op1 = curr_instr[2] -- "2"
mode_of_op2 = curr_instr[3] -- "2"
op1_value = curr_instr[4..7] -- "0005"
op2_value = curr_instr[8..11] -- "0008"
Then you just visualize the virtual system as having Eu as
it's machine code, with each memory address storing one atom.
I think it suits Core War rather well....)
BTW - Anyone who hasn't read the Core War articles in "The
Armchair Universe" might want to see if your library has it, just
so you can see where I'm coming from with some of this--I admit,
apart from the original articles some of it (like one full
instruction per address) might seem odd. 
Rod
3. Re: CoreWars issues
- Posted by simulat <simulat at INTERGATE.BC.CA>
Aug 25, 1999
-
Last edited Aug 26, 1999
> [Bytes vs Bits?]
>
> Martin, I'm not sure what [any of us] mean by a btye, but here's my
> definition:
Call me old fashioned, but I think a byte is 8 bits. I know! I'm a stick in
the mud! But I think it might be easier all round.
> 12099960044 - this is not a byte, this is a complete instruction
we agree
> 4 - this *is* a byte, a part of the instruction
Looks like a digit to me
>
> Every full instruction is 11 bytes long.
Seems like a lot to me
> Here's the breakdown:
>
> opcode: 1 byte (0-9)
only 10 opcodes
> 1st operand mode: 1 byte (0-2)
> 2nd operand mode: 1 byte (0-2)
> 1st operand: 4 bytes (0000-9999)
only 10000 possible values
> 2nd operand: 4 bytes (0000-9999)
But what if we did this:
opcode = 4 bits - This allows space for 16 opcodes, not the 10 you have now
1st op mode = 2 bits - This allows for 4 modes, but we only need 3
2nd op mode = 2 bits - This allows for 4 modes, but we only need 3
Number of bits in opcode and modes = 8 = 1 byte.
So opcode and modes are all stored in 1 byte, but give room for all the
corewars opcodes.
1st operand = 2 bytes - This allows integer values 0 - 63535.
2nd operand = 2 bytes - This allows integer values 0 - 63535.
So the whole instruction, opcode, modes and operands are all carried in 5
bytes with room to grow, where the way it works now an instruction takes 11
bytes, and already you're running out of namespace.
Notice too that the opcodes + the modes end up giving a separate value for
each possible combination of opcode and modes. It probably wouldn't be too
hard to massage that into something that would run through the instruction
interpreter that Rod has already made. And we could probably find low-level
bit operations that would make the massaging process really fast.
Anyway - I'll write up a few routines to handle this and see what you think.
Honest - this isn't a quagmire
(what was that sucking sound?)
Bye
Martin
>
> Probably not the best naming convention, but oh well :)
>
> A feature my CWC prototype includes is 2-byte opcodes. This overcomes the
> 10 opcode limit imposed by having it as 1 byte. So the instruction:
>
> 12099960044 (1-2-0-9996-0044) -- 11 bytes long
>
> using 2 byte opcodes would translate to:
>
> 012099960044 (01-2-0-9996-0044) -- 12 bytes long
>
> Of course, in order for it to work with Rod's CW he'll have to code
> support for it into his math routines. My prototype compiler still
> handles
> 1 byte opcodes (by default); to compile to 2-byte you use a commandline
> flag.
> Maybe Rod can handle 2-byte using a flag too?
>
>
> >I assumed that 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.
>
> I can see where you're coming from on this one...
>
> 12099960044 -- 11 bits = 1 byte
> 4 -- 1 bit = 1/11 byte
>
> Maybe we should make a standard way of referring to compiled data? I
> would
> prefer [my interpretation of?] Martin's method.
>
> I know the feeling Martin: from looking at Rod's code, I first thought
> that
> each bit of an instruction was a sequence element. After I ran through it
> with
> trace on, I realized that each _byte_ (full instruction) occupied a
> sequence element. Sometimes it's hard to figure out how internal data is
> stored just by looking at the
> code :)
>
>
>
> [Instruction Storage In-Core]
>
> >personally, I don't think it's a good idea (storing a complete
> instruction):
> >
> > a) It gets too far away from the Corewars that the rest of the world
> plays.
> > b) There is quite a bit of overhead involved in translating the big
> numbers
> > into instructions, and moving them around... for a display.
> > c) Besides getting away from corewars, this virtual machine gets away
> from
> > being like a computer too.
>
> Well, sofar there's two ways to do it:
>
> 1. Store each bit of an instruction in one sequence element. Basically a
> full
> instruction is 11 elements long ( or CORE[FirstBit..FirstBit+11] ).
>
> Pros:
> There's no need for any parsing functions to separate the different
> bits.
>
> Cons:
> The Core sequence gets 11x larger, possibly causing slowdowns.
>
> 2. Store each full instruction in one sequence element (the current
> method).
>
> Pros:
> Keeps the Core down to a decent size, and init'ing the Core to
> CORESIZE
> only requires repeat(0, CORESIZE) and not repeat(0, CORESIZE * 11)
> (not that it matters much :)
>
> Cons:
> Requires a routine to do bit munging before operating on an
> instruction,
> possibly causing slowdowns (like Martin mentioned).
>
>
> Personally, I favor the 2nd method, because although it does need some
> intermediate parsing of the numbers, it takes up less space overall, and
> what
> would you rather have: sequence size overhead or a little routine
> overhead?
>
> The original idea of CoreWars was to act like an abstracted computer
> system,
> but since we've gone so far from the norm anyway, why not stay in that
> direction?
>
>
> Thus endeth my comments for today,
>
> ----->Buddy
> budmeister1 at juno.com
>
4. Re: CoreWars issues
>>Unless every compiler has the same capabilities, exchanging CoreScript
>>with others might be a problem :)
>That's not to say I still wouldn't suggest a standard, or wind up
>recommending one specific compiler, or even eventually changing
>my mind and integrating something. But I just don't think it
>would be best for me to deal with that right now.
How about someone writes a smallish working draft, and describes
the basic elements every compiler and simulator should support?
>>One way to solve this is everytime you come out with a new version Rod,
>>release a specs document that describes all the guts of your program.
>That sounds like a good idea. Possibly even a suggested spec
>for the compilers themselves.
When I released my compiler today, I included a specification doc
(manual.txt) that described just about every aspect of my compiler
I could think of. How about reading through that and seeing if
it's worth using?
The thing about people doing wierd stuff with language changes is:
they have to code it themselves. It took me a whole day to get
my compiler code solid; unless they just mod someone else's code for
their
own purposes and release it as a new compiler, it wouldn't be worth
the trouble.
Still, things could get interesting...
----->Buddy
budmeister1 at juno.com
