Article 2489 of rec.games.corewar: Newsgroups: rec.games.corewar Path: hellgate.utah.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!torn!watserv2.uwaterloo.ca!undergrad.math.uwaterloo.ca!clgonsal From: clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) Subject: Re: Kind of newbie... Message-ID: Sender: news@undergrad.math.uwaterloo.ca (news spool owner) Organization: University of Waterloo References: <2k32ld$lku@agate.berkeley.edu> Date: Sat, 19 Feb 1994 02:45:30 GMT Lines: 129 >>I noticed a few odd things about the ICWS'94 proposal: > >>First, it says the default behaviour for ORG is 0. If the first line of the >>program is a DAT won't this kill it? GCW currently always executes the >>first non-DAT instruction. > >You're completely right. GCW is thus smarter than any other known corewar >interpreter, as far as this behaviour is concerned. However, in the interest >of speed and efficiency, most modern programs do not start at the first >instruction (or even the first non-DAT instruction), so the default behaviour >is not quite as important as it would otherwise be. Since there was no ORG in ICWS'88, wouldn't the default behaviour be sort of important there? >>Also, no mention is made as to whether labels are case-sensitive. Would it >>be safe to assume they are not? > >It's implementation-dependent. You can choose; I'd recommend case-insens. This is what I preffer too... >>Oh, and what would a line like this: >> >>foo bar EQU 6 >> >>do? ie: is foo a label, or an equate? > >Both foo and bar would reference the number 6. Oh well... The reason I was asking was actually twofold. First, I'd like to know in any case, because this point isn't touched on in the proposal. Second, I would've liked to have kept GCWS similar to it's current form, which is actually free-form (as opposed to line oriented). Other than comments, it seemed like nothing else really *needed* the carriage returns, so I treated them as white-space. Unfortunately, it seems that because of EQU's behaviour, CR's will actually end up playing a role. I'll probably have all of the labels picked up after a CR thrown into some sort of buffer. If I hit an EQU then they become "macros", if I don't hit an EQU, or I hit an instruction first, then they'll be treated as normal labels. >>Actually, all instructions have sightly messed up grammar. Expressions of >>the form: >> >>MOV #, # >>are valid according to the grammar. How is this treated? Just assume 0 if >>no actual value is given? > >Yes. Okay, simple enough. I still thing\k the grammar relating to the pseudo-instructions is wrong though. Somehow the line: ORG.AB #6, >8 doesn't seem valid to me. According to the grammar it is. I could treat ORG as a regular instruction I suppose... but it still looks funny. EQU is completely different from the other instructions though. They're all number oriented, while EQU is character oriented. >>Also, I saw a post that talked of an imp something like: >> >>MOV.I #a, b >> >>What will this do? How can "#a" be a full instruction? Does it just assume >>that if a uses immediate addressing for this mode then it means copy >>itself? > >Any time when you have immediate addressing, it is internally translated by >the interpreter into a reference to the current instruction. Thus, a "normal" >instruction like MOV.AB #5, 20 will treat the #5 as a reference to the current >instruction, so the interpreter looks at the A-field of the current instruction >which is of course #5. This may seem like a round-about way to interpret a >very simple instruction, but its use is in its extensibility. That is, an >"abnormal" instruction like MOV.I #5, 20 is interpreted exactly the same way, >except that since the interpreter was told (by the .I) to use the entire >instruction, it copies the entire MOV.I #5, 20 to the proper position. Okay, got it. This actually simplifies writing the interpreter quite a bit as everything's systematic. I like that in a language. May not be intuitively obvious, but heck, it makes sense! :-) >I look forward to seeing your interpreter; it will be the second '94 corewar >interpreter to come into existence! BTW, what platforms do you plan to >support? Well, currently GCW is on the Amiga only. Most of the code is ANSI C though, so to port it to anything else I'd just have to re-write the graphics routines (which are fairly simple, and segregated from the rest of the code). I haven't even looked at the code for GCW in a while, because I didn't have any good redcode to test on it. I did write a few tiny redcode programs, but it's hard to get far when you're just competeing against yourself. :-) Here's a really simple one I wrote. Note that the redcode may seem a bit mutant. GCW's redcode is basically the original Scientific American flavour: ;redcode ;name Froggy ;author C. L. Gonsalves ;strategy Will try to jump over attackers approaching from lower memory ;strategy (ie: imps) dat 0 dat -252 mov #7 -98 cmp -99 #7 jmp -1 mov @-5 @-4 cmp -6 #12 jmp 4 add #1 -8 add #1 -8 jmp -5 mov #-252 -261 jmp -261 Anyways, I want to try updating it's interpreter. I've seen some really neat code here I'd like to try on GCW. -- __ __/// clgonsal@undergrad.math.uwaterloo.ca - Only Amiga Makes it Possible! \XX/ Life is pain. Anyone who says differently is trying to sell something