04:21:58 -!- heatsink has joined.
05:13:43 -!- heatsink has quit (Read error: 60 (Operation timed out)).
05:23:28 -!- heatsink has joined.
05:58:15 -!- heatsink has quit ("Leaving").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
17:20:10 -!- kosmikus|away has changed nick to kosmikus.
17:31:56 -!- calamari_ has joined.
17:32:02 <calamari_> hi
17:32:45 <fizzie> 'vening.
17:37:16 <calamari_> morning :)
17:40:45 <fizzie> I must do a physical relocation; away 30 minutes.
17:42:40 <calamari_> ran into a small hiccup with call(gosub) & return.. it needs a place to return to (the next instruction).  I've thought of 3 schemes to handle it.  1) start temp labels at -1 (problem: big number when 32-bit) 2) labels 2x, temp labels 2x+1 (problem: on-gosub,goto get messed up), 3) have user specify and create return label (problem: annoying)
17:45:22 <calamari_> I'm leaning toward 3, because it is the easiest to implement, but it doesn't remove the main problem: there is no IP (instuction pointer)
17:53:12 <calamari_> hrm.. I think I'm going with 3.. seems like it gives the most power (don't have to return to where you came from) and least problems
18:00:28 <fizzie> returned.
18:01:11 <fizzie> still doing the assembly language? 
18:04:15 <calamari_> yeah
18:04:46 <calamari_> I realized I don't really need a call/gosub if I'm going to do it this way.. return is nice tho
18:04:56 <fizzie> do call/cc.
18:04:59 <calamari_> (call = push, jmp)
18:06:07 <calamari_> fizzie: call would have been jsr.. return is ret
18:06:19 <calamari_> unless I misunderstood what you were saying
18:07:21 <fizzie> no, I mean I want a "call/cc" instruction in your assembly language, the call-with-current-continuation from scheme.
18:07:43 <calamari_> I don't know what that is
18:08:00 <calamari_> (never used scheme)
18:08:10 <fizzie> it probably doesn't make much sense in a language without closures.
18:08:41 <calamari_> I have the major stuff done, just a few things remain now
18:08:47 <fizzie> it's a bit like setjmp/longjmp in C.
18:09:45 <calamari_> jmp's are all register based, so an ongoto is simple
18:10:29 <fizzie> then you "just" need a c compiler which creates code for your assembler.
18:10:37 <calamari_> right
18:11:27 <fizzie> does your assembly language look like a 'normal' computer? I mean registers, labels you can use as storage and such? 
18:11:28 <calamari_> I haven't finished implementing the STK command (to set the stack size).. also need to understand/use a few of dbc's compare and divide/mod routines
18:11:39 <calamari_> fizzie: yes & no.. 
18:11:54 <calamari_> there are 4 registers
18:12:12 <calamari_> stack (accessible via push & pop only)
18:12:32 <calamari_> memory (random access)
18:13:07 <calamari_> labels are made with code
18:13:55 <fizzie> mhm-well, it doesn't sound too strange.
18:14:33 <calamari_> jmp's are made up an "endless" loop and of a bunch of tests, i.e.: this is line 4, you wanted 13, keep going, etc, until a match is found
18:14:56 <calamari_> (same way as bfbasic)
18:15:36 <calamari_> yeah, I tried to make it as nmormal as possible, except this gosub thing was being a pain
18:15:36 <fizzie> sounds that any non-trivial C programs will compile to rather big blobs of brainfuck.
18:15:43 <calamari_> yes
18:16:02 <calamari_> the code will be huge
18:16:32 <calamari_> I need to write a new bf interpreter that can handle large code and data 
18:16:39 <calamari_> (unless you know of one)
18:18:32 <fizzie> nnope. but you can write a brainf*ck->befunge translator, probably some funge98 interpreters handle pretty big source files since the spec defines an infinite playfield.
18:18:36 <calamari_> oh.. also need to put in some kind of automated text -> bf at the beginning, because I use a lot of strings for bfasm  
18:18:47 <fizzie> plus that would get you a nice constant-ish "times n" increase to the "binary" size.
18:19:26 <calamari_> lol
18:28:29 -!- Toreun has joined.
18:36:10 <calamari_> bbl
18:36:12 -!- calamari_ has quit ("Leaving").
22:56:10 -!- kosmikus has changed nick to kosmikus|away.