00:00:00 --- log: started forth/12.06.26 00:05:27 --- join: ttmrichter (~ttmrichte@60.169.25.156) joined #forth 00:05:27 --- mode: ChanServ set +v ttmrichter 00:12:32 --- join: malyn_ (~malyn@unaffiliated/malyn) joined #forth 00:12:37 --- mode: ChanServ set +v malyn_ 00:12:52 --- quit: malyn (Write error: Broken pipe) 00:13:26 --- nick: malyn_ -> malyn 00:18:11 --- join: DGASAU` (~user@91.218.144.129) joined #forth 00:18:14 --- mode: ChanServ set +v DGASAU` 00:19:52 --- quit: DGASAU (Write error: Broken pipe) 00:37:32 --- join: jillsmitt (~jillsmitt@95.58.181.153) joined #forth 00:37:32 --- mode: ChanServ set +v jillsmitt 02:24:22 --- join: ASau (~user@95-28-55-240.broadband.corbina.ru) joined #forth 02:24:33 --- mode: ChanServ set +v ASau 04:59:45 It depends on stack machine. 05:01:13 (Previously, there was a tradition that people pursuing Ph.D. should at least look for prior art before answering questions.) 05:11:45 --- nick: DGASAU` -> DGASAU 06:01:34 --- join: nighty- (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 06:01:43 --- mode: ChanServ set +v nighty- 06:52:37 --- join: Onionnion (~ryan@adsl-69-215-131-241.dsl.milwwi.ameritech.net) joined #forth 06:52:41 --- mode: ChanServ set +v Onionnion 06:53:49 --- join: fantazo (~fantazo@213.129.230.10) joined #forth 06:53:52 --- mode: ChanServ set +v fantazo 07:13:52 --- quit: Onionnion (Quit: Leaving) 08:01:46 --- quit: ttmrichter (Quit: Leaving) 09:12:54 --- quit: phirsch (Read error: Operation timed out) 09:16:47 --- quit: fantazo (Read error: Operation timed out) 09:21:12 --- join: phirsch (~phirsch@xdsl-89-0-90-239.netcologne.de) joined #forth 09:21:13 --- mode: ChanServ set +v phirsch 09:37:22 --- join: Monevii (~Monevii@adsl-207-204-147-103.prtc.net) joined #forth 09:37:22 --- mode: ChanServ set +v Monevii 09:38:29 --- join: Kumul (~Kumul@adsl-207-204-147-103.prtc.net) joined #forth 09:38:34 --- mode: ChanServ set +v Kumul 10:10:29 --- quit: jillsmitt (Ping timeout: 240 seconds) 11:16:51 --- join: entwislegrove (~Duncan_En@host81-159-168-94.range81-159.btcentralplus.com) joined #forth 11:16:53 --- mode: ChanServ set +v entwislegrove 12:23:57 --- join: fantazo (~fantazo@213.129.230.10) joined #forth 12:24:21 --- mode: ChanServ set +v fantazo 12:43:25 --- quit: entwislegrove (Read error: Connection reset by peer) 12:45:33 I know GNU Forth uses at least 5 different stacks... data, floating point, return, locals, and leave stack 12:46:05 what does the "leave" stack mean, if you can say it in seven words 12:46:08 strictly speaking the local stack isn't really a stack, it's more of a scratch memory area allocated kind of like a stack 12:46:34 control-flow stack entries for all the unresolved "leave"s 12:47:06 that's straight from the manual... and I know it makes zero sense to those unfamiliar with GNU Forth 12:47:14 --- join: tathi (~josh@dsl-216-227-118-127.fairpoint.net) joined #forth 12:47:19 --- mode: ChanServ set +v tathi 13:25:27 IIRC, locals stack is real stack in gforth. 13:25:53 If you assume that "real" means contiguous memory region. 13:26:03 In any case locals are definitly organized in stack. 13:29:00 --- quit: fantazo (Read error: Operation timed out) 13:35:45 you cannot have locals on the data stack 13:36:06 but you can put them on the nesting stack, if you're masochistic 13:36:07 You can have them on the return stack. 13:36:10 yeah 13:36:28 of course you have to be masochistic to use locals at all :-) 13:36:31 It is hard to tell what is masochistic and what isn't. 13:36:45 You have to be masochistic to use Forth at all. 13:36:52 not really 13:37:00 If you use saner languages, all these problems don't matter. 13:37:12 many things are much simpler to do in forth 13:37:23 it is not a problem! 13:37:29 Like writing simplistic interpreters. :) 13:37:41 wanting to use that weird locals thing, *that* is the problem 13:39:00 The problem is that you have to juggle stack cells instead of using local variables. 13:39:10 (Which are not variable in most cases.) 13:39:29 you do not have to juggle stack cells 13:39:53 if you keep them nice and tidy, and factor well, there is no need for juggling 13:40:12 You cannot keep "nice and tidy" in many advanced algorithms. 13:40:25 i haven't met many yet 13:40:40 actually only two, in twenty years 13:40:41 This "keep nice and tidy" forces you to use ineffective polynomial algorithms in many cases. 13:40:56 uh what? 13:41:00 Or overspecialize subroutines. 13:41:27 Or make them nonreentrant. 13:41:53 heck, i make everything that uses data non-reentrant. that is ON PURPOSE 13:42:00 it's a huge simplification 13:42:19 It is huge simplification only until the next change of specification. 13:42:26 if you want it to be reentrant, just wrap it in a context 13:42:35 which is no code change 13:42:42 This is far from being "nice and tidy". 13:43:03 that's what the user pointer _is for_, eh 13:44:36 User pointer is for multitasking rather than for reentrancy. 13:44:43 You confuse two issues. 13:44:54 i don't 13:45:11 you can use it for whatever context you want 13:45:35 heck, you can have a few user pointers if you really want 13:46:03 All just to work around the problem that Forth doesn't support local variables. :D 13:46:19 Or at least it doesn't support them well enough. 13:46:29 not at all 13:47:06 i absolutely totally do not miss that i have to name all my temporaries 13:47:14 and you *do* have stack frames 13:48:06 Stack frames are not a problem at all. 13:48:48 scrolling back up... locals make code readable that otherwise resemble a cross between Sanskrit and "code that went through a trash compactor" 13:48:50 It is implementation detail, one doesn't need to care of. 13:49:37 I've done the same thing both ways... I'd rather use locals than some pick, roll, rot, swap, etc. song and dance 13:50:13 DocPlatypus: according to segher you're asking for a problem. 13:50:44 i would rather _not_ use locals and certainly _not_ use pick rol rot 13:51:08 (and i don't use swap a lot, i'm a >r r> addict) 13:51:10 then again I am a fan of the braces syntax for locals, which technically don't exist in the standard though GNU Forth ships with nice compatibility code for single-cell locals 13:51:27 I only begrudgingly use >r r> 13:51:44 >r r> are more problem than solution. 13:51:49 why would you ever name your temps? you use them only once or twice anyway! 13:51:55 it has to be a rare case when locals would be more trouble than they are worth 13:52:16 >r r> prompts for using MMU and corresponding solutions in interpreter, 13:52:26 if you want to develop interactively. 13:52:26 huh? 13:52:48 it's trivial to make >r work in the interpreter 13:53:06 six or so lines of code 13:53:08 It is not trivial to make interpreter recover. 13:53:09 best known example is in my implementations of dand, dor, dxor 13:53:38 just use a *separate* stack for the interpreter's version of >r r> 13:53:39 Making >r work is nothing, making it work _correctly_ is Problem. 13:53:43 : dlogic { a b c d x } a c x execute b d x execute ; 13:53:56 then 13:54:08 : dand ['] and dlogic ; 13:54:09 etc 13:54:17 Yikes. :) 13:54:31 : dlogic >r >r swap r> r@ execute r> execute ; 13:54:39 omg 13:54:39 : dlogic >r swap r> r@ execute r> execute ; 13:54:52 Implement interpreter so that it recovers correctly after that. 13:54:57 that's almost unreadable 13:55:19 not for me 13:55:24 DocPlatypus: you need to practice more. 13:55:32 commented heavily with stack comments, it's barely acceptable to me. 13:56:04 and let me say that usually you will be able to put the args to dlogic in a saner order 13:56:06 segher: masochist train themselves to lift pain level. 13:56:59 and maybe I do need to "practice" more 13:57:00 docplatypus: the thing with >r is, you keep all args in the same order, you just shift your "focus", what is the top item 13:57:11 now here's a good one 13:57:14 ud* 13:57:17 segher: the order there is correct. 13:57:33 multiply two unsigned doubles giving a quad 13:57:38 very easy to do with locals. 13:57:41 If you usually fetch double cell values for this kind of operations. 13:58:04 if you split them up into single cell locals... 13:58:50 you need a couple of helper words to do it the way I did it, but it's not the mess it would be trying to do it without locals 13:59:35 : ud* { a b c d -- q } a c um* b c um* rot uds+ a d um* umd+ b d um* d+ ; 13:59:39 you just use um*, what's the issue? 13:59:53 The data path is the issue. 13:59:59 you have a different um* it seems 14:00:09 'cause you need four of-em 14:00:20 He has four of them in fact. 14:00:29 that's what i say 14:00:36 (So who needs more practice?) 14:00:38 um* multiplies two single cell numbers and returns a double. 14:00:56 oh ok, that one :-) 14:01:14 to multiply two doubles, you need four um* and then to add the cells 14:01:41 In reality you can go with three multiplications. 14:01:44 nah, you need two 2*1 multiplies; and for that 2*1, you need two 1*1's 14:01:47 But whatever... 14:02:35 ASau: for ud**2 you only need three um* but for a generic multiply you need four 14:02:50 DocPlatypus: no, you need 3 for generic multiplication. 14:02:58 how?! 14:03:01 That's exactly the problem with Forth lovers. 14:03:05 because you lose the top bits anyway ? 14:03:09 this I have to see 14:03:09 Read about Karatsuba algorithm. 14:03:23 no, two doubles multiplied into a quad 14:03:27 oh. 14:03:29 nothing ever gets lost that way 14:03:58 --- quit: nighty- (Quit: Disappears in a puff of smoke) 14:05:12 ASau: that's a little misleading, isn't it? I thought you had to go significantly bigger for Karatsuba to pay off. 14:05:31 "As a rule of thumb, Karatsuba is usually faster when the multiplicands are longer than 320–640 bits." 14:05:49 tathi: it depends on relative cost of operations. 14:05:50 from Wikipedia. 14:06:05 how many Forths do you know that have 160-bit cells? 14:06:19 tathi: make the cost of multiplication larger, and you'll run into the state when it pays off immediatly. 14:06:33 ASau: Yeah, I suppose if you're on embedded hardware that could happen 14:07:10 I could, if I get bored enough, try rewriting those using Karatsuba 14:09:19 --- join: Onionnion (~ryan@adsl-69-215-131-49.dsl.milwwi.ameritech.net) joined #forth 14:09:25 --- mode: ChanServ set +v Onionnion 14:09:34 AFAIR, there exist faster multiplication algorithms. 14:10:09 --- join: fantazo (~fantazo@91.119.197.227) joined #forth 14:10:09 --- mode: ChanServ set +v fantazo 14:11:04 We have a parallel team at work, you'd like their attitude. 14:11:28 They don't know anything about algorithms, 14:11:53 and thus they put fixed length arrays and round-robin scheduling 14:11:55 everywhere. 14:12:03 Whether it fits or not, doesn't matter. 14:19:27 ASau, THANK YOU! Now we know that ALL forth programmers are stupid senseless asses. Well done. 14:21:20 Perhaps you should check logs before you start replying in the end of relatively long talk. 14:35:38 --- join: RodgerTheGreat (~rodger@71-13-215-128.dhcp.mrqt.mi.charter.com) joined #forth 14:35:42 --- mode: ChanServ set +v RodgerTheGreat 14:41:51 ASau, please tell us the story, why you found out that forth is for the dumbfuck? 15:00:35 i'm just waiting for the autobiography to be released 15:00:50 same story but in convenient chapter form 15:01:22 oh, hey- looks like Chuck put some new ColorForth stuff up on his site: http://www.colorforth.com/blog.htm 15:01:46 it appears to be mainly discussing the things he talked about at his last "fireside chat" 15:02:41 ooh he has fivefingers too 15:02:50 yeah 15:03:03 --- quit: tathi (Quit: leaving) 15:05:07 he's basically describing bitbanging VGA 15:15:54 --- join: jillsmitt (~jillsmitt@46.227.184.169) joined #forth 15:16:01 --- mode: ChanServ set +v jillsmitt 15:28:45 kulp, yeah the special edition, with an extra of 300 pages on why forth is especially gross in todays world. 16:14:56 --- quit: SplinterOfChaos (Read error: Connection reset by peer) 17:02:21 --- quit: jillsmitt (Read error: Connection reset by peer) 17:53:25 --- join: ttmrichter (~ttmrichte@61.184.205.204) joined #forth 17:53:25 --- mode: ChanServ set +v ttmrichter 18:07:51 --- join: Kumool (~Kumul@adsl-207-204-147-103.prtc.net) joined #forth 18:07:55 --- mode: ChanServ set +v Kumool 18:19:11 --- quit: Kumool (Quit: gone) 18:19:39 --- join: Kumool (~Kumul@adsl-207-204-147-103.prtc.net) joined #forth 18:19:49 --- mode: ChanServ set +v Kumool 20:53:53 --- quit: RodgerTheGreat (Quit: RodgerTheGreat) 20:56:45 --- quit: ttmrichter (Ping timeout: 245 seconds) 20:57:40 --- join: ttmrichter (~ttmrichte@113.106.102.172) joined #forth 20:57:52 --- mode: ChanServ set +v ttmrichter 21:20:21 --- quit: Kumul (Quit: gone) 21:33:46 --- quit: phirsch (Ping timeout: 248 seconds) 21:38:47 --- join: phirsch (~phirsch@xdsl-89-0-88-129.netcologne.de) joined #forth 21:38:51 --- mode: ChanServ set +v phirsch 22:31:57 --- quit: Onionnion (Quit: Leaving) 23:05:58 --- quit: ttmrichter (Ping timeout: 265 seconds) 23:06:48 --- join: ttmrichter (~ttmrichte@221.234.38.61) joined #forth 23:06:52 --- mode: ChanServ set +v ttmrichter 23:37:36 --- quit: fantazo (Remote host closed the connection) 23:45:56 --- quit: karswell (Ping timeout: 252 seconds) 23:48:31 --- quit: Kumool (Quit: gone) 23:50:48 --- join: karswell (~coat@93-97-29-243.zone5.bethere.co.uk) joined #forth 23:50:51 --- mode: ChanServ set +v karswell 23:53:05 --- quit: Monevii (Remote host closed the connection) 23:59:59 --- log: ended forth/12.06.26