←2004-08-03 2004-08-04 2004-08-05→ ↑2004 ↑all
04:23:48 -!- fizzie_ has quit (niven.freenode.net irc.freenode.net).
04:23:48 -!- deltab has quit (niven.freenode.net irc.freenode.net).
04:23:48 -!- lament has quit (niven.freenode.net irc.freenode.net).
04:26:31 -!- fizzie has joined.
04:29:35 -!- lament has joined.
04:34:08 -!- fizzie_ has joined.
04:34:08 -!- deltab has joined.
04:34:14 -!- deltab has quit (Operation timed out).
04:34:33 -!- fizzie_ has quit (Read error: 54 (Connection reset by peer)).
05:21:17 -!- heatsink has joined.
05:46:41 -!- calamari_ has joined.
05:46:45 <calamari_> hi
05:47:46 <calamari_> wrote a non-recursive parser from scratch today to handle RL assoc things like = and the unary op's.
05:48:36 <calamari_> I guess the only reason I mention that is that bfcc isn't dead :)
05:48:58 <calamari_> glad I didn't have to use a recursive parser
06:02:33 <heatsink> yea that makes it much easier
06:06:10 <calamari_> still trying to figure out how I'm going to actually do assigns and ++/--
06:08:21 <heatsink> what is ++/--?
06:08:40 <calamari_> pre-increment or pre-decrement
06:09:09 <heatsink> you're compiling from C to bf?
06:09:40 <calamari_> 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.
06:09:44 <calamari_> heatsink: yes
06:10:23 <calamari_> the situation a=b is simple, because the address is known
06:10:42 <heatsink> okay
06:11:03 <calamari_> however a[b] turns into *(&a+(b))
06:11:19 <heatsink> right
06:11:28 <heatsink> no
06:11:36 <calamari_> (if it's an rvalue)
06:11:39 <heatsink> it turns into *((a)+(b))
06:12:08 <calamari_> if it's an lvalue you only want (&a+(b))
06:13:52 <heatsink> I think you want *((a)+(b)) in both cases
06:15:12 <calamari_> heatsink: well lets say &a = 100; b=2 and the value at 102 is 4. *(&a+b) gives 4
06:15:27 <calamari_> you don't want to assign to that memory address
06:15:30 <calamari_> (4)
06:15:43 <heatsink> C doesn't allow you to say &a = 100;
06:15:50 <heatsink> Because &a isn't an l-value
06:16:34 <heatsink> Okay, I think I understand. a contains 100 and b contains 2
06:16:43 <heatsink> then *(&a+b) is 4
06:17:53 <calamari_> right, sorry about the confusion
06:17:56 <heatsink> What if you have something like getAddress() = getOtherAddress()
06:18:43 <calamari_> my parser wouldn't recognize a function as an lvalue, so who knows what would happen
06:18:59 <heatsink> okay
06:19:21 <heatsink> The way I would parse an assignment statement is different from how you're doing it
06:19:50 <heatsink> ...or the way I would convert it to low-level instructions anyway
06:20:31 <calamari_> I might be confusing the issue, because when I think about pointers I tend to revert to assembly language concepts
06:22:27 <heatsink> I would reduce the LHS and RHS of an assignment to an expression the same way
06:22:35 <calamari_> okay
06:22:41 <heatsink> Then take a reference to the LHS
06:22:53 <heatsink> and use that as the address to store the value of the RHS into
06:23:28 <heatsink> a[b] = c[d]
06:23:49 <heatsink> &( *(a+b) ) <-- *(c+d)
06:23:57 <heatsink> or
06:24:29 <heatsink> MEM[&*(a+b)] <-- *(c+d)
06:25:19 <calamari_> 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
06:25:43 <heatsink> You are manipulating expressions, not evaluating them
06:25:59 <heatsink> there's just a rule that &*x = x
06:26:12 <heatsink> unless x is not a pointer type
06:28:22 <heatsink> I think you need an IR to do it this way
06:28:45 <heatsink> If you convert it to assembly as soon as possible, you lose the information you need
06:28:49 <calamari_> IR?
06:28:54 <heatsink> intermediate representation
06:28:57 <calamari_> oic
06:30:40 <heatsink> This will work with function calls, pre & post increment, which is nice
06:33:26 <heatsink> *++a = b is ({a = a+1; MEM[&*a] = b;}) ...... *a++ = b is ({temp = a; a = a+1; MEM[&*a] = b;})
06:34:10 <heatsink> I guess my approach implies an IR; no way around it that I can see
06:35:14 <heatsink> Do you begin printing output before you finish reading input?
06:37:55 <calamari_> yes
06:38:46 <calamari_> hehe
06:39:25 <heatsink> I see... a lightweight translator then
06:40:15 <calamari_> I don't want to use much memory, because that is slow in BF
06:40:31 <calamari_> that = array memory
06:40:58 <heatsink> Well, here's a question for you. What will the following code do?
06:41:14 <heatsink> int *a; int b;
06:41:29 <heatsink> *a = (int) &a;
06:41:38 <calamari_> there is no int * a;
06:41:43 <heatsink> *a++ = b;
06:41:50 <heatsink> you don't have pointers?
06:41:54 <calamari_> you can only do int a; or int a[number]
06:42:51 <calamari_> If you need memory you could do something like a=malloc(1000)
06:43:21 <calamari_> then use it with a[0], a[1], etc
06:43:55 <calamari_> also, no casts
06:44:09 <heatsink> so the language is strictly typed
06:47:02 <calamari_> I'm not sure what that means, I guess :)
06:48:08 <calamari_> I wanted to avoid messed up situations like int ******* a;
06:49:26 <calamari_> anyhow.. I'll keep thinking on it and see if I can come up with something
06:52:28 <heatsink> That's a good method
06:53:28 <calamari_> thanks for you suggestions
07:01:50 -!- calamari_ has quit ("Leaving").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:02:19 -!- heatsink has quit ("sleep").
10:20:25 -!- deltab has joined.
21:34:18 -!- calamari_ has joined.
21:34:23 <calamari_> hi
21:54:07 <calamari_> 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
21:56:32 <calamari_> only problem right now is that it accepts things like *(a+5)
21:56:47 <calamari_> (where a is defined as int a;)
21:57:27 <calamari_> to fix that I'd need casts
21:59:33 <fizzie> in comp.lang.c one of the old-timers remarked that early C:s allowed you to dereference an integer constant, like:
21:59:36 <fizzie> struct rkreg { int csr; int dar; int wc; };
21:59:38 <fizzie> 0777440->dar = addr;
21:59:41 <fizzie> 0777440->wc = 256; /* one sector */
21:59:44 <fizzie> 0777440->csr = RK_READ | RK_GO; /* read the sector */
22:03:28 <calamari_> I'm figuring right now it's okay as long as valid c works as expected
22:07:20 <calamari_> btw, no structs atm
23:53:07 -!- calamari_ has quit ("Leaving").
←2004-08-03 2004-08-04 2004-08-05→ ↑2004 ↑all