OpenEuphoria

Re: CoreWars issues

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Aug 25, 1999
• 399 views

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