00:22:23 oh god. 00:22:58 my Normalizer decreases the size of wib from 6287 to 6097 instructions. 00:23:27 that's 3%! 00:23:39 i wonder if it still works afterwards... :) 00:27:16 Clearly people don't bother about optimizing their Brainfuck code at all! 00:28:28 oh, and there has to be a way to normalize things containing ., and not just +-<> 00:28:53 or maybe not... 00:29:53 >>>>>.<<<<<+>+>+>+>+> clearly should be +>+>+>+>+>. 00:30:13 but my normalizer would not touch it. 00:30:54 -!- andreou has joined. 00:33:50 well, isn't it enough to gather all the +s and -s affecting the cell you're .ing or ,ing from/to and make sure those happen in order. not sure how your "normal form" is specified though. 00:34:13 uh-oh, it's already past 02:30 here, I think I'll sleep some. 01:38:03 one hour later, same situation 01:38:04 -!- andreou has quit ("If it doesn't have 36 bits, you're not playing with a full DEC."). 02:42:51 -!- andreou has joined. 03:54:53 -!- calamari_ has joined. 03:54:56 hi 04:14:56 g'evening 04:16:54 hi 04:16:56 I was thinking about the c compiler.. a valid way to do it is c -> asm, then asm -> binary (bf). That would actually be pretty neat, because then the c compiler doesn't have to worry about many details 04:17:25 yeah 04:17:29 perhaps even asm->basic? :) 04:17:32 basic->brainfuck 04:17:39 that's disgustingly complex 04:17:40 I like it 04:18:01 lol 04:19:02 bfbasic could be rewritten to support the asm, removing a lot of the limitations 04:19:39 that will certainly be quite neat. 04:21:54 I was thinking about 32-bit cells.. it would take a lot of work and bloat the code if 32-bit cells had to be emulated with four 8-bit cells. 04:23:15 so the bf interpreter/compiler will probably need to be 32-bit 04:24:46 that's fine. 04:26:36 afaict signed and unsigned math is pretty much the same (except when reporting overflow situations), but comparisons don't work the same way 04:30:05 any suggestions on how to do a signed compare of > or absolutely amazing stuff. 05:03:29 aha, I think I have found a way. if after a decrement a number equals 127 then an answer reversal byte is toggled. it has to be toggled because if both numbers were negative then the compare works like if it were positive 05:04:18 (i.e. -2>-3 is the same as 6>5 in a 3-bit mode) 06:18:36 -!- calamari_ has quit ("Leaving"). 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 09:35:02 -!- andreou has joined. 09:40:50 -!- captor has joined. 10:00:42 -!- andreou has quit (Read error: 113 (No route to host)). 10:09:15 -!- captor has quit (Read error: 60 (Operation timed out)). 14:18:01 -!- grumpy_old_one has quit (calvino.freenode.net irc.freenode.net). 14:18:01 -!- lament has quit (calvino.freenode.net irc.freenode.net). 14:18:03 -!- ChanServ has quit (calvino.freenode.net irc.freenode.net). 14:18:06 -!- kosmikus has quit (calvino.freenode.net irc.freenode.net). 14:18:06 -!- mtve has quit (calvino.freenode.net irc.freenode.net). 14:18:07 -!- cmeme has quit (calvino.freenode.net irc.freenode.net). 14:18:08 -!- mooz- has quit (calvino.freenode.net irc.freenode.net). 14:18:08 -!- fizzie has quit (calvino.freenode.net irc.freenode.net). 14:18:09 -!- deltab has quit (calvino.freenode.net irc.freenode.net). 14:18:09 -!- Taaus has quit (calvino.freenode.net irc.freenode.net). 14:18:09 -!- edwinb has quit (calvino.freenode.net irc.freenode.net). 14:18:47 -!- grumpy_old_one has joined. 14:18:47 -!- lament has joined. 14:18:55 -!- edwinb has joined. 14:19:14 -!- ChanServ has joined. 14:19:14 -!- kosmikus has joined. 14:19:14 -!- mtve has joined. 14:19:14 -!- irc.freenode.net has set channel mode: +o ChanServ. 14:19:44 -!- cmeme has joined. 14:19:44 -!- mooz- has joined. 14:19:44 -!- Taaus has joined. 14:19:44 -!- deltab has joined. 14:19:44 -!- fizzie has joined. 16:50:06 -!- calamari_ has joined. 16:50:17 hi 17:48:05 hi 18:02:10 optimizing BF .,<>+- sequences is tough. 18:02:20 i'm trying to figure out a nice way to do it. 18:03:04 for example, >+<.>,<- should be optimized to .->, 18:04:27 ideally, the optimizer should be written in brainfuck. 18:07:49 why? 18:08:08 just convert it to bf when you're done :) 18:08:23 what, you've already written your c->BF compiler? :) 18:08:45 nope.. working on the assembler. it's going slow, though, because I' 18:08:57 m only using if's, labels, and gotos 18:09:11 (for easy translation of the assembler to bfasm :) 18:09:14 how would you do IO? 18:09:22 assembly programs call the kernel for that. 18:09:26 You'll be emulating the kernel? 18:09:49 ?? there are two asm instructions in_ and out, for that 18:10:23 er 18:10:31 these instructions are actually produced by GCC? 18:10:36 no 18:10:36 when compiling a printf? 18:10:39 there :) 18:10:46 I'm not using gcc 18:10:49 -!- kosmikus has changed nick to kosmikus|away. 18:10:51 what are you using? 18:11:04 the asm compiler would be not very interesting if you wouldn't be able to use it to compile C to BF 18:11:45 gcc isn't the only way to compile c to asm.. I was writing my own c compiler 18:12:00 oh. 18:12:11 I realized that if I wrote an assembler, the c compiler would be a lot easier to do 18:13:35 besides, gcc doesn't really put much code at all for a printf.. it pushes the operands and calls printf 18:13:58 printf can do whatever you want.. that's handled during linking 18:15:58 but, I gave up trying to figure out the gcc backend. I'm sure there is documentation somewhere on how to do it, but I couldn't find any that I understood 18:48:17 meh, was writing my own '.,<>+-'-sequence-optimizer but managed to forget that ">,<." cannot be optimized to ".," really. 18:49:44 uh, I obviously mean ".>," 18:50:41 fizzie: no! let me write it!! :) 18:52:07 although i'm not entirely sure how to do it. 18:53:25 Of course it has to be able to optimize ++++++, to , 18:54:29 other than the IO-in-order problem I think a relatively clean way is to gather the strings of operations applied to every cell to an array, then optimize those and recreate a suitable >[ops]>[ops]-like thing. but that would happily transform >,<. to .>, 18:55:07 "optimize those" would mean at least "remove all +-s before a ," and "combine all series of +-s" 18:56:17 what are you writing it in? 18:57:30 well, I wrote few lines (80) in C but I'm not sure whether I want to think about the IO ordering. maybe I'll indeed let you write it. 18:58:51 :) 18:59:22 my 72-line python program optimizes +-<> sequences. 18:59:37 i'll probably have to rewrite it from scratch though :| 19:00:44 but really, it should be written in Brainfuck. 19:00:50 The trick is to find a good algorithm. 19:05:08 yay, bfasm parses the instructions and operands.. now to do the hard work of generating bf code 19:10:17 Ooh, i think i came up with an algorithm. 19:10:51 implementing should be trivial now. 19:11:35 it's almost easier than my original implementation. 19:44:21 * lament is stumped 19:44:24 <+>>+< 19:45:10 correction 19:45:14 <+>>>+<< 19:45:29 >>+<<<+> 19:45:30 ... 19:45:32 wicked. 20:16:52 woohoo! 20:16:54 i think i wrote it 20:17:05 Show us the source! 20:17:07 er 20:17:11 no, i haven't :) 20:19:07 ok, i think i have now. 20:19:24 Can you give me some +-,.<> sequences to optimize? :) 20:20:02 gah more bugs 20:20:55 :( 20:21:17 How does it optimise ">>>>,<<"? 20:21:39 you can't optimize that. 20:21:52 ,+[-.,+] 20:23:25 hmm cool, if eof=0 then it's ,[.,] 20:24:01 never thought of that before.. dunno why :) 20:24:05 ok, now it's definitely done 20:25:24 give me sequences! :) 20:25:41 fuck. 20:25:54 >++.>+.+++++++..+++.>++.<<++++++++++++ 20:25:55 +++.>.+++.------.--------.>+.>. 20:26:00 oops 20:26:19 >++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>. 20:26:33 it shouldn't be able to do anything with that 20:31:35 give me better sequences 20:31:40 lol 20:31:47 did it stay the same? 20:32:55 ,,,,, 20:33:05 ... 20:33:11 well actually 20:33:37 yeah. blah. 20:33:43 None of them got any shorter. 20:33:50 good 20:34:06 FUCK 20:34:13 I just accidentally deleted the source. 20:34:19 :))))))))))))))))))))))))))))) 20:35:12 really? 20:35:26 hope you're using fat/fat32 .. undelete :) 20:36:00 ext2 20:36:40 phew 20:36:45 i had vim open in another window 20:36:54 with that file 20:37:27 it's safe. 20:42:23 +++.--- 20:43:02 +-+.-+- 20:43:19 more bugs though :| 20:45:01 -!- calamari- has joined. 20:54:13 this needs a rewrite anyway. 21:03:04 ok 21:03:07 i think _now_ i did it. 21:03:49 it's much simpler now too. 21:04:45 also broken. 21:04:47 -!- calamari_ has quit (Read error: 110 (Connection timed out)). 21:05:25 crap. 21:05:46 crap, crap. 21:08:15 crap. 21:15:37 ok 21:15:43 it better work now!!! 21:16:08 there's a nice ook-like bf "variant": crap! "crap. crap. crap? crap! crap! crap?" 21:17:22 yeah. 21:17:38 but i'm _sure_ i got it working now. 21:17:39 :) 21:18:54 ... and i'm still wrong :( 21:19:53 I hate programming. 21:20:09 lament: do you have bfbasic? I'd be curious to know what your program does with some of the compiled examples 21:20:18 or I can dcc 21:20:36 actually, nm.. it can't do [] yet 21:22:52 bbl.. work 21:22:53 -!- calamari- has quit ("Leaving"). 21:58:05 :[ 22:07:47 graah 22:07:53 i thought i have a bug 22:07:58 but actually i don't 22:08:12 oh the humiliation. 22:08:16 no bug for you, lament! 22:08:26 well, now i'm _damn sure_ i'm done :) 22:08:37 just like the last N times? 22:08:49 no. 22:08:52 those times, the bugs were real. 22:09:03 give me a sequence! :) 22:10:17 well uh I haven't written much befunge, and this hw2.bf (t-106.231 course homework) doesn't seem to have any long sequences to optimize. 22:10:37 it's a brainfuck, not befunge, optimizer 22:10:56 hw2.bf is brainf*ck. 22:11:00 I use .bef for befunge. 22:11:09 14:10 well uh I haven't written much befunge, 22:11:21 well, that just means my brain is misfired. 22:11:24 what does hw2.bf do? 22:11:31 miswired. gah. 22:11:52 converts ascii-binary to ascii-decimal, I think. something like that anyway. 22:12:13 actually it converts ascii-binary to "real binary" (single brainf*ck cell) and then prints that as decimal. 22:12:18 a short four-line ditty. 22:12:42 paste it! 22:13:16 it's not very nice brainf*ck, I think. 22:13:21 +[>,----------[>++++++[<------>-]<-->>[->++<]>[-<+>]<<<[>>+<<[-]]<+>]<-]>>> 22:13:22 >>>++++++++++>+<<<<[>>>>>+[->>+>+<[<<+>>-]<<[>+>+<<-]++++++++++>[<->-]<[[-]>>+++ 22:13:26 +++++++>>-<<<<]>>---------->>+]+[-<<[<<+>>-]<<[>+>+<<-]>----------[<+>[+]]<]<-]> 22:13:29 >>>->>>>[>>>>]<<<<[<<++++++[>++++++++<-]>.<<<]++++++++++. 22:13:30 plus that might be the buggy version too. 22:13:43 the printer didn't like '0's. 22:14:09 I have a non-buggy version too, but I'm not quite sure where. 22:15:14 first line is the 'read ascii binary' line, last three are an ugly "print as decimal" routine. 22:15:55 uses lots of cells too, something like 3*decimal-digits or 4*decimal-digits of the number. 22:16:54 ok, you're right. 22:17:08 the optimizer does nothing of interest. 22:17:28 apart from rearranging the code to its liking. 22:17:55 well yeah, I see no reason to write unoptimized ><+-,. sequences when writing code manually. :p 22:19:48 you could do it accidentally. 22:20:08 I see no reason to make mistakes. 22:21:18 heh. 22:21:29 heh. 22:21:41 Compared to my +-<> optimizer, this thing is almost useless. 22:22:15 wib.b (the brainfuck->c compiler) is 6288 instructions. 22:22:35 optimized +-<> it's 6098 instructions. 22:22:46 optimized +-<>,. it's 6092. 22:23:42 would be interesting to try it on calamari's generated code, though. 22:32:21 heh. 22:32:25 it's surprisingly efficient. 22:32:30 (calamari's bfbasic) 22:33:56 next optimize .,<>+-[] strings. 22:34:26 -!- Toreun has quit (Read error: 104 (Connection reset by peer)). 22:34:27 to provably shortest possible equivalent code. 22:34:39 :))) 22:34:40 Right. 22:34:52 Now, there's just the simple matter of that being impossible. 22:35:00 excuses. 22:35:07 just write some python code to do it. 22:35:17 I hear python makes the impossible possible. 22:36:46 true. 22:40:56 hm 22:41:05 optimizing -+,.<>[] is of course impossible. 22:41:11 but what about -+,.<>[ ? :) 22:46:18 hahaha 22:47:14 the optimized version of 99 bottles produces _longer_ binary when compiled with bfc 22:48:16 (although the C code is of equal size for both) 23:07:11 -!- mooz- has quit (calvino.freenode.net irc.freenode.net). 23:07:11 -!- fizzie has quit (calvino.freenode.net irc.freenode.net). 23:07:11 -!- deltab has quit (calvino.freenode.net irc.freenode.net). 23:07:11 -!- Taaus has quit (calvino.freenode.net irc.freenode.net). 23:07:13 -!- cmeme has quit (calvino.freenode.net irc.freenode.net). 23:07:14 -!- ChanServ has quit (calvino.freenode.net irc.freenode.net). 23:07:15 -!- mtve has quit (calvino.freenode.net irc.freenode.net). 23:07:15 -!- kosmikus|away has quit (calvino.freenode.net irc.freenode.net). 23:07:40 -!- edwinb has quit (calvino.freenode.net irc.freenode.net). 23:07:45 -!- ChanServ has joined. 23:07:45 -!- edwinb has joined. 23:07:45 -!- kosmikus|away has joined. 23:07:45 -!- mtve has joined. 23:07:45 -!- cmeme has joined. 23:07:45 -!- mooz- has joined. 23:07:45 -!- Taaus has joined. 23:07:45 -!- deltab has joined. 23:07:45 -!- fizzie has joined. 23:07:45 -!- irc.freenode.net has set channel mode: +o ChanServ. 23:35:56 -!- Toreun has joined.