Re: More Core War
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET> Aug 23, 1999
- 323 views
>>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. I was thinking ICWS'88 compatability (as the first 'standard' standard to support), but not getting there anytime soon... Y'know, something to do down the line.. Anyway, 'fun' sounds good too. :) >As for pMARS, it's been around as long as CoreWar has, and it's here to >stay (with its infinite complexities). I figured a graphical Llama version (once Llama is ready) would be cool, as it'd be able to run on anything Llama can run on. Of course, it'll be a while until that happens... (It'd definetally be more user-friendly than a command-line version that makes you want to code a shell like PSHELL for it. :) >>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 Yep, that's what happens... I'll explain my method at the end of this e-mail. >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? I see some areas where that would help. It doesn't support it yet, I'm going to look at some expression evaluators written in Euphoria. >>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. Well CMP was in the original Core War. A SLT would be helpful, as well. That way, a program can do better counters, and check if areas in code have been damaged. (A JZ is easy to trick, just bomb with 1's or 34's or whatever instead of 0's) >>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 ;) I'll probably wait until the new version is out before I clean up my version. Ok, on to label support.. I looked at how pMARS handles labels. Here's how they are handled: hi there i am a jmp hi Is treated as hi JMP hi or JMP 0 Basically, the first 'word' is the label if it isn't an instruction. So, here's what I do: I scan all the lines. If the first word of the line isn't an instruction, and it fits the label rules (starts with a letter, rest is alphanumeric) then I add it to the list labels. If a colon is found at the end of a label, it is removed before it is put in the list. (Since colons are optional in ending labels and are never used in referencing a label.) Labels are stored in a sequence, each element containing {sequence label, integer line}. Once all the labels have been found, I go through the list again to convert each parsed line (the first time through I break them up into each 'word') into the atom format for CoreWars to read. While doing this, if a label is found, I replace it with the number it should be (by doing a labels[thislabel][2] - currentline). After the labels are converted, I could use someone's expression evaluater to evaluate, umm.. any expressions. :) I haven't plugged this in yet, though. Currently, if you put in something like: A few too many labels MOV 0, 1 It is treated the same as if you put in: a: DAT 0, 1 or a DAT 1 Since the instruction parser expects the instruction to be first, and the label finder removes the label from the line when it finds a label. (And 'few' isn't a valid instruction.) (All labels are converted to lowercase during parsing.) I don't know if I should 'fix' this or not. :)