[01:04] MSG: Ping timeout: 245 seconds [02:07] Join: Norrit joined #corewars [03:38] MSG: Ping timeout: 245 seconds [08:12] jamesstan: seq and sne usually compare whole instructions, slt only values. Seq/sne make a comparement as a single decision - equal/nonequal, slt is a less-than/more-than decision. [08:15] slt @bomb, bomb will a) take the value of bomb's b-field b) look at the instruction that the value points to c) take a value from that instruction d) compare it to value in bomb e) skip or not skip, depending on the comparement [08:16] The indirect addressing, or in other words, using a value as a pointer, can be problemous if you dont know the concept of a pointer [08:19] i also left unmentioned in c) which value is taken (a or b), because than can be specified, but you left that off in the instruction. When unmentioned, it will become slt.b ; and compare b-field to b-field [12:32] Join: jamessta1 joined #corewars [12:32] Thank you for your information Mizcu. [12:33] The problem is that I wasn't expecting the 'b)' aspect of SLT. I was expecting it to compare the value in the B-Field. Is there any way to make this happen? [12:33] Thanks [12:35] Oh, I do understand the concept of pointers. My main language is C. I just hadn't heard it referred to as direct/indirect addressing before [12:40] Join: Norrit joined #corewars [12:40] Hello Norrit. [12:41] Hi, Hows it going? [12:42] It is going well [12:42] Are you also well? [12:42] good to hear [12:42] hopefully soon. Trying to figure out where my wallet went currently [12:42] Oh dear [12:43] Is that the reason for the frequent disconnections? ISP kicking you off? :p [12:44] haha, No, usually thats just me moving my laptop around an being too lazy to do anything about IRC [12:44] jamesstan: what do you want to compare the b-field to? you want to compare two b-fields? or just two numbers? [12:44] should I be careful of that with the extensive use of logs on here? [12:45] Mizcu, I want to compare the value in the b-field of the instruction that bomb points to with the actual address of bomb [12:46] It is to ensure that the number in the b-field of bomb is larger than the length of the program [12:46] Thinking about it, I'll probably want to have bomb+1 [12:47] slt.ab #distance-to-bomb, bomb [12:48] OK Thanks, I'll try that now. [12:48] you can actually use slt.ab #bomb, bomb , as long as "bomb" refers to an instruction [12:48] I was just about to ask that ;) [12:51] there is a thing about Slt i have to note [12:51] oh? [12:51] in CW, when addresses become larger than coresize/2, it wraps around to -coresize [12:52] but in slt, the value doesnt wrap [12:52] I thought that was only when they became larger than coresize? [12:52] well, yeah [12:52] OK [12:52] thats how it officially goes, and how it happens in corewin [12:53] Could this affect me if bomb is only around 4 instructions away? [12:53] so you are right, and i am just influenced by pmars.. [12:53] Don't worry, I am also using pmars [12:53] have a good day guys [12:53] anyway, largest value possible is coresize-1 [12:53] Will do, Norrit [12:53] MSG: [12:53] Yea, [12:53] I read that [12:54] if you want to prevent self-bombing with slt, this creates problem, because values before slt are more valuable than those in front of [12:54] OK, that's exactly what I'm trying to do. [12:54] I need to go now, so bye! [12:54] MSG: Quit: leaving [12:55] if you want to use something to extent of "dont bomb if its less than 24 instructions away", this will mean "24 instructions away from slt" [12:56] and thus, instructions before slt are 'more than 24 instructions away' [12:56] because instructions 'behind' are more valuable to slt [12:57] this can be a problem, because instructions behind slt are not protected [12:57] but anyway, ill get back to what i was doing [14:54] ooh [14:55] that makes things very difficult [14:57] just make it the top instruction [15:08] ok [15:13] (and slt bomb, #last_instruction ) [15:18] right [15:55] Join: Metcalf joined #corewars [15:56] Microupdate on the energy-page.. [15:56] hi Met [15:57] Hi Mizcu [16:00] energy-page? [16:00] http://users.evtek.fi/~mikaos/energy/ [16:05] MSG: Ping timeout: 245 seconds [16:08] Join: Metcalf joined #corewars [16:11] No review of Cherry Coke :-/ [16:12] nothing special + not ED [16:16] Lucozade is the only energy drink I've tried (if it counts) [16:17] its a Sports Drink, which is different [16:18] (what, no Red Bull?) [16:21] Never [16:22] well, thats a good thing, really [16:23] You're also missing Explosade. [16:23] too much sugar -> diabetes [16:23] Although Explosade is a crappy rip-off of Lucosade. [16:23] never sold here [16:24] OK [16:24] im not from UK [16:24] I can see [16:24] You're from Finland [16:25] Gatorade is only one ive seen here, plus that-one that is produced locally [16:25] james: which part of the U.K. are you from? I'm from Lincs [16:25] Cheltenham [16:25] in Gloucestershire [16:27] Hmmm... never been there [16:27] I've never been to Lincolnshire (that right?) either [16:28] You're not missing much! [16:28] ha [16:29] There's a place called Corwar in Scotland :-) [16:30] Nice [16:35] I just starting coding something, and now I have to go out :-( [16:40] Can anyone tell me what a binary launch is? [16:41] explaining the whole thing? [16:42] Well either that or link me to a page or some commented code, please [16:43] theres a lot of code around, lemme check if i can find one that has only a binary launch [16:44] OK [16:44] are you researching Imp-spirals, or just found the term somewhere? [16:44] I am reading something called 'My first Corewar book' and it mentions a binary launch in the imp spiral section [16:44] I wondered what it was [16:45] an imp spiral is a structure where multiple imps work together to form a single 'thing' [16:45] OK [16:45] for imp spiral to exist, it must be started (duh). The problem is that all of the processes have to be at right place, and they must run in correct order. [16:46] Right [16:46] http://www.ociw.edu/~birk/COREWAR/94/HILL/insight.red <- between lines spiral and imp [16:47] That's a binary launcher? [16:47] damn, theres a couple extra lines in it too [16:47] hasty action gets hasty results.. [16:48] I don't mind. I appreciate that you're trying to help me [16:49] ignore those last three spl -lines in the code [16:49] OK [16:49] but back to the imp-launching [16:49] so - a program starts with a single process - and to add more, a spl has to be used [16:50] OK [16:50] IIRC, the B-Field is ignored...? [16:51] Oh I see, there's a comment about the B-Field. [16:51] so, the first process run a spl to create another process - this second process is set to halfway of code (we dont know how big the launch will be, but that can be ignored for now) [16:51] the b-field is not ignored, but for the purpose of warrior, they dont do anything important [16:51] OK [16:52] so now we have two processes - if that is not enough, we will set spl's under each - they will double to four. Continue 'dividing' until required amount of processes is gained [16:53] Alright [16:53] you will have code something to extent of ****-*-*-*-*-*-* .... where * is a spl [16:53] OK [16:53] then put a jmp into every - [16:53] in that row, the processes run from left to right - in correct order [16:54] so the first - will be jmp location1, second - a jmp location2, and so on [16:54] where is location1 and 2? [16:54] they depend on what kind of imp spiral you are launching [16:54] OK [16:56] after each jmp has run, the processes will run again - except this time they are in right place, and position to start up an imp spiral [16:56] i see [16:57] this example will become more problemous if you need an amount of processes which is not a power of two - you need to replace some of the spl's with something that is not a jmp [16:58] Ah, yeah [16:58] ugh, replace some of the spl with *something* that does not affect the process [16:58] Hence binary [16:58] MSG: Ping timeout: 245 seconds [16:59] so technically you build a launcher by building a binary tree, with each dividing being a spl, each straight being 'something else', and each end a jmp [16:59] then you take the tree, and violently turn it on the side to get the code [16:59] Join: Metcalf joined #corewars [16:59] I see [16:59] however, binary launch is not used anymore [16:59] Oh? [17:00] it becomes _really big_ when you try to launch larger spirals, and there are better launches (smaller) [17:01] Right [17:01] binary launch is optimal by speed, so in that way it can only be tied [17:01] I saw a thread in the IRC logs while Googling for binary launcher. You named a few in there [17:02] jmp/add -launcher is really small and can launch huge spirals, but it has only about 2/3 of the speed [17:02] Alright [17:03] vector launch is just as fast, but smaller [17:05] Then there are self-priming "imp pumps", which are a breed of their own, because they launch a small spiral, and then keep making it bigger; they are also microscopic compared to others. These are whan modern warriors use. [17:05] OK. [17:08] I've just found a FAQ and it has an example binary launch in it (just thought I'd let you know in case someone else asks). [17:08] I found the FAQ after you explained, by the way. [17:08] http://www.ecst.csuchico.edu/~pizza/koth/corewar-faq.html#WhatDoesMean [17:10] damnit, first thing i checked was the faq, i must be getting blind [17:10] Ha [17:14] One more thing, I just read 'jmp @0,imp', isn't that exactly the same as 'jmp imp'? [17:14] yes it is [17:15] OK [17:15] the reason why that is used in the example is that under '88 standard you could not add into the a-field [17:15] and since you wanted to change the value of "imp", you had to move it into b-field, and thus use jmp @0, imp [17:16] under '94 standard you can add into the a-field, and that trickery is no longer needed [17:16] Ah [17:25] Join: YuanTi joined #corewars [17:27] hi there [17:28] hi [17:28] dont mind me [17:29] Right [17:40] Is it the case that there will /never/ be a negative number in core war maths? [17:40] AFAICT, it should be but isn't [17:48] MSG: Ping timeout: 245 seconds [17:48] Join: Metcalf joined #corewars [17:53] jamesstan: thats is bit of a philosophical question really [17:54] I mean, as far as SLT is concerned [17:54] You mentioned something about it earlier, but I wasn't sure [17:54] philospohically, how do add #-1, #1 and add #(coresize-1), #1 differ? [17:54] You can use negative numbers, but they're stored mod coresize. [17:55] Will 'SLT -1, 1' always think -1 is larger than 1, for instance? [17:55] yes. (Slt #-1, #1 , that is) [17:55] Right [17:55] despite this most stuff still works [17:55] OK then. [17:57] Another thing, does the pre-processor always convert labels in instruction parameters to the relative number? [17:58] i am bit confused about that question, in what context? [17:59] Erm [17:59] Is '#label' valid, basically? [17:59] And will it get me a number which refers to the distance to the label? [17:59] it depends on the label, but yes, it is [17:59] OK [17:59] if label refers to an instruction, it will give you the distance to it [17:59] Yep [17:59] if label refers to a value, it is used as a value [18:00] OK [18:00] MSG: Ping timeout: 245 seconds [18:01] imp: MOV imp, imp+1 turns into MOV 0, 1 , while: number equ 155 | mov number, number+1 turns into mov 155, 156 [18:01] Join: Metcalf joined #corewars [18:01] Alright [18:02] mov #location1 - location2, somewhere - where location1 is 5 cells before and location2 is 7 cells after will convert to [18:02] double-using a label will lead to an error message from the pre-processor and erratic behaviour (thats kinda obvious, ainnit?) [18:03] mov # (-5) - (7), somewhere -> mov # -12, somewhere [18:03] -12 mod coresize = 7988 [18:03] Is '#location1 - location2' equivalent to '#location1 - #location2'? [18:03] Or can you only specify and addressing mode once? [18:04] only once [18:04] OK [18:06] (though you can do *number*multiplier..) [18:07] Ha [18:13] MSG: Ping timeout: 245 seconds [18:15] Join: Metcalf joined #corewars [18:15] ah, yes, found out the brainbender i found at little less than month ago [18:15] gotta mark it up somewhere [18:15] Hmm? [18:16] i founded something that didnt behave like the model of core i have in my mind [18:17] i never did get any opinion back about it from Metcalf (though it was pretty much insignificant) [18:17] Ah [18:18] The only time I've had a problem with negative numbers being stored mod coresize is code like div # 2, # -4 [18:20] I see [18:23] MSG: Ping timeout: 245 seconds [18:37] I just read this: 'slt #0, s', won't 0 ALWAYS be less than s? [18:40] yes [18:40] OK. So why would somebody have included that line? [18:41] Mistake? [18:41] where did you read it? [18:41] It was in Sample Bomber in the 94 open hill on Koneigstuhl [18:43] thats a faulty warrior [18:43] thats why its the second last in there too [18:43] OK [18:43] I looked at the ones at the bottom to see what I could be contending with :P [18:43] (and thats not "open", thats nop, or 'NO P-space') [18:43] Oh? [18:44] It says 'CoreWar 94-Open - Koenigstuhl' in the title bar [18:45] http://www.ociw.edu/~birk/COREWAR/koenigstuhl.html - i dont see an 'open' -hill there [18:46] ah, Draft -hill calls itself 'open' [18:46] nevermind, then [18:47] (from second last to last.. did i mention it is faulty?) [18:47] You did [18:48] the Odd -hill also calls itself Draft, which is kinda silly [18:48] Ha [19:12] I am still having trouble with SLT (sorry for pestering). I can't make it compare the value in the B-Field with the distance to the instruction. Can you explain again, please, if you have time? [19:13] That is, the value in the B-Field of a separate instruction [19:13] what is the whole code you have? [19:14] http://stanley.homelinux.org/barty.red [19:14] (I've just noticed that the jmp barty in bombchecker is redundant) [19:15] you are comparing not the value of bomb, but the value at the place that will be bombed next [19:15] just take the @ off [19:16] oh? [19:16] off the slt [19:16] that still doesn't work [19:16] either that or something else is wrong [19:16] does it work in your mars? [19:17] you mean, the prevention of self-bombing doesnt work [19:17] yes [19:17] and it doesn't bomb anywhere else at all [19:17] in fact, the only place it bombs is itself [19:24] http://pastebin.com/d64bb2423 [19:26] ok [19:26] what i did really was that i only moved the bomb behind the slt [19:27] that works! [19:28] why did the bomb need to be moved? [19:30] in the previous discussion, i mentioned that all values 'behind' slt are bombed while those 'after' were protected - but the comparing was done to a value inside the bomb, so the protected are was that after the bomb [19:31] right [19:31] are -> area [19:31] yeah