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
>
|
Not Categorized, Please Help
|
|
