< 1091593428 0 :fizzie_!unknown@unknown.invalid QUIT :niven.freenode.net irc.freenode.net < 1091593428 0 :deltab!unknown@unknown.invalid QUIT :niven.freenode.net irc.freenode.net < 1091593428 0 :lament!unknown@unknown.invalid QUIT :niven.freenode.net irc.freenode.net < 1091593591 0 :fizzie!fis@sesefras.tky.hut.fi JOIN :#esoteric < 1091593775 0 :lament!~lament@S01060050baab2c59.vc.shawcable.net JOIN :#esoteric < 1091594048 0 :fizzie_!fis@sesefras.tky.hut.fi JOIN :#esoteric < 1091594048 0 :deltab!~deltab@espians.com JOIN :#esoteric < 1091594054 0 :deltab!unknown@unknown.invalid QUIT :Operation timed out < 1091594073 0 :fizzie_!unknown@unknown.invalid QUIT :Read error: 54 (Connection reset by peer) < 1091596877 0 :heatsink!cirodrig@c-67-161-51-181.client.comcast.net JOIN :#esoteric < 1091598401 0 :calamari_!JeffryJohn@dialup-4.240.111.29.Dial1.Phoenix1.Level3.net JOIN :#esoteric < 1091598405 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :hi < 1091598466 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :wrote a non-recursive parser from scratch today to handle RL assoc things like = and the unary op's. < 1091598516 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I guess the only reason I mention that is that bfcc isn't dead :) < 1091598538 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :glad I didn't have to use a recursive parser < 1091599353 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :yea that makes it much easier < 1091599570 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :still trying to figure out how I'm going to actually do assigns and ++/-- < 1091599701 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :what is ++/--? < 1091599720 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :pre-increment or pre-decrement < 1091599749 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :you're compiling from C to bf? < 1091599780 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :basically the situation is that I'm using registers during evaluation.. for example a=b turns into something like r1=a, r2=b, r1=r2.. however that doesn't transfer the value of b to a.. only to r1. < 1091599784 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :heatsink: yes < 1091599823 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :the situation a=b is simple, because the address is known < 1091599842 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :okay < 1091599863 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :however a[b] turns into *(&a+(b)) < 1091599879 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :right < 1091599888 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :no < 1091599896 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :(if it's an rvalue) < 1091599899 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :it turns into *((a)+(b)) < 1091599928 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :if it's an lvalue you only want (&a+(b)) < 1091600032 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I think you want *((a)+(b)) in both cases < 1091600112 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :heatsink: well lets say &a = 100; b=2 and the value at 102 is 4. *(&a+b) gives 4 < 1091600127 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :you don't want to assign to that memory address < 1091600130 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :(4) < 1091600143 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :C doesn't allow you to say &a = 100; < 1091600150 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Because &a isn't an l-value < 1091600194 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Okay, I think I understand. a contains 100 and b contains 2 < 1091600203 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :then *(&a+b) is 4 < 1091600273 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :right, sorry about the confusion < 1091600276 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :What if you have something like getAddress() = getOtherAddress() < 1091600323 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :my parser wouldn't recognize a function as an lvalue, so who knows what would happen < 1091600339 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :okay < 1091600361 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :The way I would parse an assignment statement is different from how you're doing it < 1091600390 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :...or the way I would convert it to low-level instructions anyway < 1091600431 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I might be confusing the issue, because when I think about pointers I tend to revert to assembly language concepts < 1091600547 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I would reduce the LHS and RHS of an assignment to an expression the same way < 1091600555 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :okay < 1091600561 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Then take a reference to the LHS < 1091600573 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :and use that as the address to store the value of the RHS into < 1091600608 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric : a[b] = c[d] < 1091600629 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric : &( *(a+b) ) <-- *(c+d) < 1091600637 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :or < 1091600669 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :MEM[&*(a+b)] <-- *(c+d) < 1091600719 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :okay, that's my problem.. how is &*() possible? Once I do the *, I have a 4, and I can't think of how to gget back to 102 < 1091600743 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :You are manipulating expressions, not evaluating them < 1091600759 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :there's just a rule that &*x = x < 1091600772 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :unless x is not a pointer type < 1091600902 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I think you need an IR to do it this way < 1091600925 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :If you convert it to assembly as soon as possible, you lose the information you need < 1091600929 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :IR? < 1091600934 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :intermediate representation < 1091600937 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :oic < 1091601040 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :This will work with function calls, pre & post increment, which is nice < 1091601206 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :*++a = b is ({a = a+1; MEM[&*a] = b;}) ...... *a++ = b is ({temp = a; a = a+1; MEM[&*a] = b;}) < 1091601250 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I guess my approach implies an IR; no way around it that I can see < 1091601314 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Do you begin printing output before you finish reading input? < 1091601475 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :yes < 1091601526 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :hehe < 1091601565 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I see... a lightweight translator then < 1091601615 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I don't want to use much memory, because that is slow in BF < 1091601631 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :that = array memory < 1091601658 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Well, here's a question for you. What will the following code do? < 1091601674 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :int *a; int b; < 1091601689 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :*a = (int) &a; < 1091601698 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :there is no int * a; < 1091601703 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :*a++ = b; < 1091601710 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :you don't have pointers? < 1091601714 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :you can only do int a; or int a[number] < 1091601771 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :If you need memory you could do something like a=malloc(1000) < 1091601801 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :then use it with a[0], a[1], etc < 1091601835 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :also, no casts < 1091601849 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :so the language is strictly typed < 1091602022 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I'm not sure what that means, I guess :) < 1091602088 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I wanted to avoid messed up situations like int ******* a; < 1091602166 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :anyhow.. I'll keep thinking on it and see if I can come up with something < 1091602348 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :That's a good method < 1091602408 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :thanks for you suggestions < 1091602910 0 :calamari_!unknown@unknown.invalid QUIT :"Leaving" < 1091606399 0 :clog!unknown@unknown.invalid QUIT :ended < 1091606400 0 :clog!unknown@unknown.invalid JOIN :#esoteric < 1091606539 0 :heatsink!unknown@unknown.invalid QUIT :"sleep" < 1091614825 0 :deltab!~deltab@espians.com JOIN :#esoteric < 1091655258 0 :calamari_!JeffryJohn@dialup-4.240.108.82.Dial1.Phoenix1.Level3.net JOIN :#esoteric < 1091655263 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :hi < 1091656447 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :got around the = and ++ -- problems by keeping track of whether the register is an address or a value. But, since I'm doing that, I might as well implement pointers all the way, since it should be trivial :P < 1091656592 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :only problem right now is that it accepts things like *(a+5) < 1091656607 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :(where a is defined as int a;) < 1091656647 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :to fix that I'd need casts < 1091656773 0 :fizzie!unknown@unknown.invalid PRIVMSG #esoteric :in comp.lang.c one of the old-timers remarked that early C:s allowed you to dereference an integer constant, like: < 1091656776 0 :fizzie!unknown@unknown.invalid PRIVMSG #esoteric :struct rkreg { int csr; int dar; int wc; }; < 1091656778 0 :fizzie!unknown@unknown.invalid PRIVMSG #esoteric :0777440->dar = addr; < 1091656781 0 :fizzie!unknown@unknown.invalid PRIVMSG #esoteric :0777440->wc = 256; /* one sector */ < 1091656784 0 :fizzie!unknown@unknown.invalid PRIVMSG #esoteric :0777440->csr = RK_READ | RK_GO; /* read the sector */ < 1091657008 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :I'm figuring right now it's okay as long as valid c works as expected < 1091657240 0 :calamari_!unknown@unknown.invalid PRIVMSG #esoteric :btw, no structs atm < 1091663587 0 :calamari_!unknown@unknown.invalid QUIT :"Leaving"