00:00:00 --- log: started forth/04.01.27 00:12:33 Well, I think I'm at a good stopping point for this evening. 00:12:39 Didn't make my goal, but I'm *fairly* close. 00:13:12 I got it to parse words and display them in order of entry on the line, regardless of line-breaks. Elegantly handles trailing white-space too. 00:15:33 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 00:24:33 --- join: Nutssh (~Foo@gh-1029.gh.rice.edu) joined #forth 00:24:57 --- quit: Nutssh (Client Quit) 00:34:26 --- part: imaginator left #forth 00:38:57 --- quit: Serg () 02:42:25 --- join: Teratogen (leontopod@intertwingled.net) joined #forth 02:57:36 say, icon is not a bad little language 02:57:38 =) 03:02:04 --- join: arke (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 03:03:36 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 03:14:27 --- quit: arke (Read error: 104 (Connection reset by peer)) 04:11:14 --- join: TheBlueWizard (TheBlueWiz@207.111.96.29) joined #forth 04:11:14 --- mode: ChanServ set +o TheBlueWizard 04:11:41 hiya all 04:58:39 gotta go...bye all 04:58:46 --- part: TheBlueWizard left #forth 05:51:50 --- quit: [Forth] ("abort" Reality Strikes Again"") 05:54:49 --- quit: I440r ("going to work") 06:56:51 --- join: downix (~downix@adsl-219-34-197.mia.bellsouth.net) joined #forth 07:02:42 --- join: arke (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 07:20:55 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 09:35:16 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 09:35:27 --- mode: ChanServ set +o kc5tja 09:37:02 Hi 09:37:08 hey Sam 09:37:14 Hello. 09:37:24 Made some more progress on FTS/Forth yesterday. 09:37:34 It doesn't yet interpret, but it does have a proper read/evaluate loop now. 09:37:36 cool 09:38:59 What architecture is that Forth system made for? 09:39:06 The bad news is that FTS/Forth has about 1/10th the speed of fully optimized C, and 1/2 the speed of generic C, code. 09:39:13 downix: x86 09:39:21 Oh, nice. 09:39:40 warpzero wants me to port to PowerPC, which I will probably take him up on once I get FTS/Forth sufficiently bootstrapped. 09:40:04 Will you implement better optimization later on? 09:40:26 Yes, my goal is to re-implement the various peephole optimizers in a later generation of the code. 09:40:50 I'm also planning on making more words machine language primitives (some are inlined, some are called). 09:41:13 hey now 09:41:26 A free and fast Forth system for x86, this could be good. :) 09:41:49 Robert: Built on the philosophies of cmForth and PygmyForth, too. 09:42:13 But, remember that it's *not* cmForth or PygmyForth. 09:42:18 What? Minimalism? 09:42:21 Very. 09:42:46 For example, this is how I define four variables in FTS/Forth right now (because of bootstrapping purposes, but still...): 09:42:53 : buffer r> ; 09:43:00 : blk buffer [ 0 , 0 , 0 , 0 , 09:43:04 : >in blk 4 + ; 09:43:08 : src blk 8 + ; 09:43:11 : #src blk 12 + ; 09:43:58 I could make >in, src, and #src their own 1-cell "buffers", but that actually takes up more space in the block than can actually fit. 09:44:31 I'll have more room to fix that when I refactor the interpreter loop to support nested blocks. 09:44:58 Are you going to use raw blocks for storing files and source code? 09:45:20 FTS/Forth currently is being built for Linux. Blocks will be kept in a "blocks.fb" file. 09:45:39 Oh. 09:45:42 When FTS/Forth is ported to run on raw hardware, then blocks will be used to touch actual hardware devices directly. 09:47:42 In fact, I really can't wait for that day, because then the overhead involved with even Linux disappears. 09:48:08 :) 09:48:31 Even if Linux is running only one process, there is still a lot of run-time overhead. 09:48:48 The kernel will periodically try to change processes, which will cause the data cache to thrash a bit. 09:49:20 And with modern CPUs taking *thousands* of cycles to fetch memory now-a-days, that can cause noticable slowdowns. 09:49:32 Some OSes are better than others with regard to this, obviously. 09:49:58 Marcel Hendrix did some comparison tests between Linux and Windows 98, and noticed that *same binaries* run an average of 15 to 20% slower under Windows 98. 09:50:17 Windows NT has no noticable sluggishness compared to Linux, but I'm willing to bet you some 20% slowdown compared to raw metal. 09:51:00 20% of 800MHz (for my box) is still 160MHz. :) Just running without an OS would make my system compare to a 966MHz computer in performance. 09:52:33 * kc5tja notes that one of the reasons the Cray supercomputers can get such insanely fast computation speeds is precisely because it *LACKS* memory management hardware. So an 800MHz Cray X1 can compete rather admirably with other supercomputers running in the 1GHz to 2GHz class quite nicely. 09:55:14 Seymour Cray strongly believed in explicitly managed storage, and the sheer speed of PC/GEOS and block-based Forth systems strongly suggest this is the proper way to go. 09:55:45 kc5tja: how do you make sure your peephole optomizations don't move stuff across a point where an IF branches to? 09:56:18 The peephole optimizers work *before* a primitive is inlined. 09:56:30 Let's consider an example, which best explains it. 09:56:41 Suppose I have a primitive called # which compiles a literal. 09:56:43 eg if you have "drop dup" optimized out and you compile this code: "if drop then 1" 09:57:28 First, you can't optimize out drop dup. :) 09:58:13 "dup drop" then? 09:58:15 The best you can hope for is to replace the drop with "mov eax,[esi]" to get teh same effect. 09:58:55 The compiler maintains pointers to the previous and current locations where it's compiling to. 09:59:07 For every word it sees, it copies the current location to the previous location. 09:59:32 Thus, after THEN is executed by the compiler, which we know doesn't compile any code, the "current" and "previous" code pointers will still point to the same location. 09:59:40 (which is where the literal 1 will go) 10:00:17 So when the DUP part of literal examines memory, it won't find the instance of DROP, because the previous code pointer is no longer pointing to it. 10:01:00 interesting 10:01:20 However, I've been considering taking a slightly alternative approach to the compiler with FTS/Forth. 10:01:34 yeah. 10:01:35 Chuck does his magic by maintaining those two pointers, and examines actual byte sequences in memory. 10:01:49 * kc5tja is thinking of maintaining a bitmap that records what the last instruction was. 10:01:58 E.g., if + was compiled, it'd set the "+" bit, etc. 10:02:27 maybe I will do that cool optomizing thing there you keep the top few stack items in whatever registers are open and you compile your inlined primitives to use whatever registers they are in 10:02:27 This makes the peephole optimizer implementation slightly easier (and certainly smaller) at the expense of greater care needed to code primitives. 10:03:12 yeah 10:03:24 well put "greater care" 10:03:43 I don't know that it would really be harder, but I imagine I would have to be careful 10:04:42 Well, if I have to be careful, it's probably going to be harder in some way (harder to debug, harder to implement, whatever). 10:04:56 In this case, it'd make it harder to debug. 10:05:08 I try to ignore optomizing (because I really like to do it, and it's completely unnessesary at this point) but when I ran that benchmark, and realized that I had about a 6X slowdown because of stack use 10:05:17 I also think it frees me up to do better optimization than Chuck currently does, because it can span a larger number of primitives. 10:05:30 yeah :) 10:05:47 I was avoiding this concept because I thought it would make my system more complex 10:05:57 but I think I could do it so it wasn't any harder to make primatives 10:06:03 Oh, it definitely makes things more complex. 10:06:04 I'm using register names as it is 10:06:07 No question there. 10:06:09 sure 10:06:20 but it migt even make it easier to make primatives. 10:06:22 But the payoff for peephole optimization is huge compared to its implementation complexity. 10:07:09 Now, a dataflow optimizer...that's something that's really complex to implement (lots of mutual recursion too, so make sure you have a large return stack!), but the payoff relative to its complexity may not be nearly as large. 10:07:19 But I'm willing to try it in the future, as a need arises. 10:07:29 my primatives that use two registers would be simplified (in source form anyway) 10:08:23 s/registers/stack items/ 10:08:44 One of the biggest optimizations I'm going to put in FTS/Forth is the auto-detection of CREATE-d words (whcih includes VARIABLEs) and turns them into literals (complete with all the subsequent peephole optimizations possible with them). 10:09:01 :) 10:09:12 I did something simular. 10:09:25 Words which have been modified with DOES> will not be detected with this scheme (which is a GOOD thing) because the target address of the leading CALL instruction will not point to (do-create). 10:09:30 my compiler can't tell the diference between numbers, constants, and variables. 10:09:45 and I don't have create. I just do HERE CONSTANT XXX 10:10:02 (except that CONSTANT is a color) 10:10:09 * kc5tja nods 10:10:47 Well, remember that I'm bootstrapping FTS/Forth, so bizarre constructs like : blk buffer [ 0 , 0 , 0 , 0 , will likely be replaced with create blk 0 , 0 , 0 , 0 , soon enough anyway 10:12:23 I also think that FTS/Forth will eventually split its code and data spaces distinctly in the future too. 10:12:29 what do you call the item under TOS? 10:12:41 The second top of stack. 10:12:53 2tos 3tos 10:14:06 I'm also thinking of rolling the interpreter main-loop and compiler loop into the same loop in FTS/Forth, kind of like how ANSI Forth is built. 10:14:14 But I won't have a STATE variable. 10:14:38 [ and ] will change two pointers: one is a pointer to a word classification word, and the latter is a pointer to a jump table. 10:15:53 iclassify will be a word that classifies for the interpret-mode, while cclassify will do the same for compile-mode. 10:16:11 (the only difference between the two is that cclassify will check the compiler vocabulary before dropping into iclassify. :)) 10:17:10 This opens up a lot of possibilities to me. Especially a *LOT* of text-processing applications. I'm very excited at the prospect of this. 10:17:24 Coding my website maintenance package in FTS/Forth may not be as hard as I anticipated if I implement this. 10:18:08 what does iclassify do? 10:18:16 Interpret-mode Classify 10:18:30 ( caddr u -- caddr u 0 | xt 1 | n 2 ) 10:18:31 what does classify do? 10:18:57 it either returns the word verbatim (word not found), returns its XT (found in FORTH vocabulary), or returns a number (it was a number). 10:18:59 Undefined, word, number 10:19:08 nice 10:19:17 cclassify would be this: ( caddr u -- caddr u 0 | xt 1 | n 2 | xt 3 ) 10:19:28 where option 3 is (it was found in the COMPILER vocabulary) 10:19:30 another identifier for immediates 10:20:07 Although, I'm going to return the constants 0, 4, 8, and optionally 12 too (e.g., they're pre-scaled for jump table use on a 32-bit system). This removes two shift operations. :) 10:20:37 identifier for immediates? What do you mean? 10:20:40 Oh, sorry. 10:20:53 For some reason I was thinking of assembly language when you said 'immediates.' :) 10:21:07 :) 10:21:29 And when you think about it, iclassify is built up from primtives too. 10:21:33 We can start at the root: 10:21:36 : undef 0 ; 10:21:53 Then make a word find-forth that returns (xt 1) if found, else drops into undef. 10:22:09 Then the word number which tries find-forth first, and if undefined, tries to convert the word to a number, etc. 10:22:48 The exact ordering isn't yet set of course, nor are the table indexes. But you get the general idea. 10:23:09 mmmmm.... it seems to me that adding an optomizer that handles immediates to the stack optomizing stuff might make it a bit messy 10:23:31 Ummm 10:23:40 I mean so "4 +" get's compiled as: addi tos, tos, 4 10:23:40 Nearly every primitive in FTS/Forth is coded as an "immediate." 10:23:47 Yes. 10:23:56 The code for + is responsible for checking to see if a literal was compiled first. 10:24:08 It is also responsible for letting the compiler know that a + was compiled. 10:24:17 This way words like @ can encode proper instruction encodings 10:24:24 E.g., 4 + @ ==> mov eax,[eax+4] 10:24:36 right 10:26:48 I also intend on optimizing the 2* and 2/ words big-time. 10:26:49 --- quit: proteusguy (Connection reset by peer) 10:27:17 2* 2* 2* 2* should expand to SHR EAX,4, not four instances of SHR EAX,1, like it currently does. :) 10:27:23 err 10:27:26 SHL rather 10:27:29 :) 10:27:54 Why not simply let the user write "4 <<" or something and then optimize that? 10:28:18 I can I suppose. 10:30:00 I am imagining a system where when you compile "4" it does not compile anything, it just keeps track of it (at compile time) and when you go to compile a primative, you check if TOS has a constant value, or a register, and compile a different instruction for each 10:30:27 You're getting into dataflow optimization. 10:30:43 That's anybody's ultimate goal. 10:31:03 Taken to the extreme, colon definitions don't even emit code. 10:31:10 They just sit in a compiler-maintained database. 10:31:29 for "+" there are three cases: 1) both are registers (values not known at compile time) add instruction 2) one value is number. addi instruction. 3) both are numbers. don't compile anything, just add them and keep track 10:31:33 Until you actually use one of the words, then code for that word, and all words it depends on, get globally optimized as a group, and code emitted on-demand. 10:31:51 spiffy 10:32:20 * kc5tja notes that code so generated competes with the likes of *highly* optimized C very easily. 10:32:31 :) :) 10:32:44 And, in fact, draws much from the arcane arts of optimizing functional programming languages. 10:32:56 :) 10:33:28 I wonder how many times I can move a value between registers in the time it takes to fetch a word from the data cache 10:33:47 If cache is on-chip, one. 10:34:01 Maybe two. 10:34:20 Depends on how many integer pipelines you have, and whether the CPU's scoreboard can properly execute them out of order. 10:35:10 weird 10:35:22 That's the thing with functional languages: due to its referential transparency, there is *zero* distinction between a macro and a function. 10:35:51 A definition can be compiled, or it can be inlined -- you don't know, and it doesn't matter to the program -- it'll still work either way. 10:36:23 Forth, being a concatenative language, exhibits this property to a very, very large extent. 10:36:38 You can easily change any arbitrar colon definition into a compiler macro, and lo and behold, the program still works. :) 10:36:50 Sometimes, but not always, vice versa too. 10:36:56 E.g., : rdrop r> r> drop >r ; 10:37:10 is an example of a "primitive" turned colon-definition that works just fine. 10:37:32 There are a couple of gotchas that you need to look out for (especially in FTS/Forth, which does tail-call optimization). 10:37:53 But for the overwhelming majority, Forth can be considered a functional language *in this sense.* 10:38:09 This is why FL-type optimization schemes and compiler schemes map so well to Forth. 10:41:49 You know, these non-destructive IF statements are coming in rather handy some things. 10:42:16 99% of the time, I use drop if or drop -if, but (especially for debugging) the non-destructive if holds its own when coding the interpreter. :) 11:07:07 * warpzero is back (gone 12:53:03) 11:08:29 * warpzero is away: Well I did not think the girl could be so cruel, and I 11:09:13 * warpzero is back (gone 00:00:44) 11:09:38 --- join: slava (~slava@CPE0080ad77a020-CM.cpe.net.cable.rogers.com) joined #forth 11:09:40 hi all 11:09:47 * warpzero is away: 11:09:48 i added a stack-effect checker to my language's compiler 11:10:05 * warpzero is away: 11:10:18 --- quit: warpzero ("Well I did not think the girl could be so cruel, and I'm never going back to my old school.") 11:10:34 ok> "testing" see 11:10:34 : testing 11:10:34 ( compiled: I I I -- O O ) 2 * + 3 swap / - 5 * sq dup ; 11:11:03 --- join: warpzero (~warpzero@dsl.142.mt.onewest.net) joined #forth 11:11:28 slava: Nice. 11:12:21 * warpzero is away: Well I did not think the girl could be so cruel, and I'm never going back to my old school. 11:12:30 That, actually, is the beginning of a dataflow optimizer. 11:13:12 kc5tja, of course in many causes it is not possible to deduce the stack effect (anything involving control flow). 11:13:24 kc5tja, the plan is to, in some cases, avoid generating any code for 'dup', 'swap', etc. 11:19:52 Anything involving control flow can have its stack effects deduced as long as things remain balanced inside and outside of the control flow. 11:20:24 kc5tja, like an 'if' with both branches having same effect, right? 11:20:33 kc5tja, i was thinking about how i could deduce the stack effect for recursive functions. 11:20:44 Words which have unbalanced stack effects are marked as such for special treatment by the optimizer and compiler. 11:21:07 slava: Yes, or a while-loop where the input and output stack effects are the same. 11:21:50 kc5tja, my plan is to use the jvm stack for definitions that fit a certain form -- where the input effect is known, and the output is either 1 or 0 (this is a limitation of the JVM). 11:22:09 it should be a bit faster than the current way, which uses an array for a stack. 11:22:24 You mean the number 1 or the number 0, or 0 or 1 stack elements? 11:22:29 0 or 1 elements 11:22:39 java methods can only return 1 value, or nothing at all. 11:22:48 * kc5tja nods 11:22:53 eg, right now the compiled form of a word like '+' is: 11:23:00 data stack -> jvm stack 11:23:02 data stack -> jvm stack 11:23:06 call + library routine 11:23:10 jvm stack -> data stack 11:23:22 (the + is a library routine to handle bignums, etc) 11:23:28 * kc5tja nods 11:23:44 so if you write a word that has a lot of arithmetic, its a waste shuffling literals, results, everything back and forth. 11:24:47 i think when the compiler is done, the performance will beat any other language hosted on top of the JVM, except java. 11:25:04 the main problem is that i'm not sure i'll ever be able to implement arithmetic without boxing. 11:29:16 You know, all things considered, I'm surprised my Forth compiler produces code that runs as fast as it does at all. 11:29:19 :) 11:29:30 I'm looking at this code, and I realize just how hhoorriibbllee it is. :) 11:29:38 It's *REALLY* bad. :) 11:31:55 fs/forth? 11:32:17 i'm sure the generated code is not as bad as mine :) 11:33:17 Are you sure about that? :) 11:33:26 I do absolutely zero peephole optimization what-so-ever. 11:33:49 * slava doesn't even know what peephole optimization is 11:37:19 Eliminates duplicate or unnecessary code on a local scale. 11:38:33 oh ok. 11:38:44 E.g., 2* 2* 2* normally would compile to SHR EAX,1 : SHR EAX,1 : SHR EAX,1 in FTS/Forth. 11:38:53 Once peephole optimization is in, it'll compile to SHR EAX,3. :) 11:39:16 hmm 11:39:26 this doesn't seem very forthish to me :) 11:39:27 the name "peephole" comes from the fact that the optimizer looks at a sliding window of code 11:39:41 why not just 3 ^2, with a suitable ^2 ? 11:39:50 oops 11:39:59 slava: Because a bit-shift doesn't compute a power, it computes a multiple. 11:40:15 i just realized that, but i mean, you can write a word *8 or something. 11:40:21 And 2* 2* 2* to compute 8 * is very Forthish. 11:40:24 Well, we normally do: 11:40:28 : 8* 2* 2* 2* ; 11:40:31 right. 11:40:49 slava: so you have a word that still emits the same code he pasted.. 11:40:58 But I'm just saying, why would we want to compute three 1-bit shifts when the peephle optimizer can just replace that whole sequence with a shift to three bits? 11:41:14 its true, but wouldn't the optimizer then need to have intimate knowledge of *2? 11:41:20 or does it work at the instruction level? 11:41:34 slava: More accurately, 2* does its own peephole optimization. 11:41:44 The compiler doesn't know nor care about what or how 2* works. 11:42:10 ok 11:42:28 : 2* previous-shift? if inc-shift-count ;; then emit-opcode ; 11:42:56 interesting 11:43:06 what is ;; 11:43:14 Whereas right now, FTS/Forth's code for 2* is just : 2* emit-opcode ; . :) 11:43:37 and emit-opcode is defined, how? 11:43:37 ;; is my word for EXIT, because I use it so often (note I lack an ELSE clause to IF; I also lack BEGIN, WHILE, REPEAT, AGAIN, UNTIL too.) 11:43:46 Well I was giving a template. 11:43:47 If you must know... 11:44:01 : 2* $d1 c, $e0 c, ; 11:44:07 : 2/ $d1 c, $f8 c, ; 11:44:56 oh right. 11:45:00 :) 11:45:02 i thought you had some kind of magic emit-opcode :) 11:45:22 Nope. Unfortunately not. 11:47:21 * kc5tja needs to start biking into work again. 11:47:40 * kc5tja is getting fat. :( I gots me a bowl full o' jelly that'd make Santa Claus happy. 11:47:57 lol 11:51:28 --- join: proteusguy (proteusguy@236.sub-166-153-177.myvzw.com) joined #forth 11:51:32 hi proteusguy 11:52:08 kc5 - do you have a word for tail-recursion? 11:52:16 once the compiler is done, i hope to move many library routines from java to factor. right now the java code is 6,000 lines, this is way too much. 11:52:29 howdy. 11:52:37 Hi proteusguy 11:52:50 cleverdra: Both ; and ;; do proper tail-call recursion. 11:53:01 kc5tja, factor does tail recursion too :) 11:53:07 its a good idea. 11:53:13 kc5 - what about general tail-call optimization? 11:53:27 cleverdra: What is the distinction between the two? 11:53:44 rehi Robert. Such a friendly little channel is forth! :P Espcially compared to #python. 11:53:55 Hi proteusguy !!! :D 11:54:01 (sorry, I couldn't resist.) 11:54:01 haha 11:54:04 proteusguy, because forth > python :) 11:54:08 kc5 - '; and ;; do proper tail-call recursion' would allow an implementation that only notices self-recursion and optimizes that 11:54:22 Oh, no, it does it for any word. 11:54:32 python forth > . = true ? 11:54:33 kc5 - 'tail-call optimization' turns all instances of 'function-call exit' into 'JMP into function' 11:54:37 kc5 - ah, OK =) 11:54:37 So, for example, if I have : foo bar baz ;, the reference to baz is turned into a JMP instead of a CALL. 11:55:17 cleverdra: It's actually MUCH easier to get full tail-call optimization than to restrict it to just the word. 11:55:19 lightbulb lights up in slava's head 11:56:44 tail-call optimization changes the way you program -- some people seem to think of it as something that you can leave to an implementation, sigh. 11:57:13 cleverdra: Well, let's just say that it's **substantially** simplified the Forth compiler. 11:57:15 Just think of writing a state machine, say, with and without tail-call optimization. 11:57:23 No traditional control flow primitives. 11:57:26 Just IF and THEN. That's it. 11:57:31 cleverdra, in my language, loops are implemented using recursion. 11:57:49 Well, because I use the CPU flags only for IF, I have "IF" and "-IF" (tests for zero, tests for sign, respectively). 11:57:50 cleverdra, thanks to tail call optimization. 11:57:56 I have for/next if/then and tail recursion. 11:58:03 you can make any construct with those 11:58:04 hi Herkamire:) 11:58:09 hi slava :) 11:58:09 i have you guys all beat 11:58:11 I may consider implementing FOR/NEXT in the future, but for now, I can live without it. 11:58:14 : ifte ? call ; 11:58:29 : ? ( condition ifT ifF -- ifT/ifF ) ... ; 11:58:30 slava - that doesn't give you enough by itself, though -- tail-recursion will allow you to write a huge state machine in one function, sure, but you can't split it up into multiple SM-NEXT'ing =) functions. 11:58:59 --- quit: ChanServ (Shutting Down) 11:59:01 cleverdra, any call at the end of a word replaces the execution pointer instead of pushing a new one 11:59:05 Actually, slava, I have you beat. :) 11:59:10 slava: you've renamed SDL --> Factor? or is factor something else? 11:59:16 Herkamire, lsd --> factor 11:59:17 IF ;; THEN 11:59:18 :) 11:59:35 slava - do you know anything about SysRPL? 12:00:30 :) I don't have ELSE in my forh 12:00:38 forth 12:00:52 --- join: ChanServ (ChanServ@services.) joined #forth 12:00:52 --- mode: brunner.freenode.net set +o ChanServ 12:02:36 I have a word that jumps to a specified address. that counts as a control construct too. and ; 12:02:41 --- join: Nutssh (~Foo@dunwlessnat.rice.edu) joined #forth 12:03:30 --- quit: slava (brunner.freenode.net irc.freenode.net) 12:03:30 --- quit: mur (brunner.freenode.net irc.freenode.net) 12:05:44 --- join: mur (~mur@mgw2.uiah.fi) joined #forth 12:07:54 I now need to implement ['] and execute in my cross-compiler. 12:08:10 --- join: slava (~slava@CPE0080ad77a020-CM.cpe.net.cable.rogers.com) joined #forth 12:08:14 --- quit: slava (Connection reset by peer) 12:08:24 Back in a bit.... 12:08:55 --- join: slava (~slava@CPE0080ad77a020-CM.cpe.net.cable.rogers.com) joined #forth 12:19:50 --- quit: Nutssh ("Client exiting") 12:26:22 --- join: Nutssh (~Foo@dunwlessnat.rice.edu) joined #forth 12:43:36 --- quit: Nutssh ("Client exiting") 12:47:42 --- join: Nutssh (~Foo@dunwlessnat.rice.edu) joined #forth 12:49:29 --- quit: arke (Read error: 104 (Connection reset by peer)) 12:54:01 --- join: arke (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 12:54:22 hi all 12:54:29 erm, oops sorry 12:54:32 hi all 12:58:26 hello arke! 12:59:30 chandler: how are you today ? 13:00:03 arke: g'day. 13:00:44 how is y'all? 13:00:56 : : : ; : ; ; ; 13:01:18 --- quit: Robert ("brb") 13:01:51 Hrm, this multiDesk for winblows actually works quite well. 13:04:37 hello , everyone ! 13:04:48 terve mur ! 13:05:31 soon sleep 13:06:15 --- join: arke_ (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 13:06:36 --- quit: arke (Read error: 54 (Connection reset by peer)) 13:06:40 --- nick: arke_ -> arke 13:08:53 hi arke 13:08:59 :) 13:10:46 arke, i'm writing the JVM local variable allocator for my compiler. 13:10:56 arke, hoping for a 3x speedup in some situations. 13:10:59 --- join: Robert (~snofs@c-185a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 13:11:33 slava: cool stuff! 13:12:12 slava: how are you doing it? (specifics) 13:12:31 arke, using the java virtual machine's local variables for the datastack, instead of an array 13:12:48 arke, and instead of generating for for swap/dup/et al, just renaming locals at compile time 13:12:57 s/for for/code for/g 13:15:43 heh :) 13:15:51 Great optimization for any forth ^_^ 13:16:13 dup, swap, drop, nip are all compile time :) 13:17:35 yes. each compiled word will be of the following form: JVM locals> stack array> 13:18:01 and if the contains calls to other words, the other word's core is called 13:18:28 :) 13:18:45 so for example in : recip 1 swap / ; there are no pointless copies between 1, swap and / 13:21:07 recip() { int a; int b; a = 1; b = stack[0]; a = a / b; stack[0] = a; } <--- like that? :) 13:23:20 --- join: _proteus (~proteusgu@216.27.161.121) joined #forth 13:24:02 --- quit: _proteus (Read error: 104 (Connection reset by peer)) 13:24:22 --- join: _proteus (~proteusgu@216.27.161.121) joined #forth 13:34:00 Hmm. Another interesting dilemma. 13:34:13 I can produce smaller, faster code if I have execute jump to the address in the A register. 13:34:37 But then I'd always have to write code like a! execute, which of course destroys the contents of the A register. 13:35:24 Or, I can have execute compile a code sequence that assumes traditional execute semantics, but which touches another register. 13:35:39 Or maybe you don't want to keep a that long 13:35:51 Or maybe add another B register, and you can choose or whatever 13:36:11 Well, execute is a primitive; I can't choose. It's one or the other. 13:36:34 Then I would say use A :) 13:36:35 The only way to choose is to redefine execute on a case-by-case (e.g., program-by-program or block-by-block) basis. 13:36:51 arke, re: your sample code; sort of :) 13:37:17 or you could have : execute-a compile a! compile execute ; immediate 13:37:28 er, otherway around 13:37:39 : execute compile a! compile execute-a ; 13:37:43 Well, that's what I'm thinking right now. 13:37:59 But I can also have postpone >r postpone ;; too. :) 13:38:01 :) 13:38:18 heh, that would be even better actually 13:38:38 --- quit: ianp (Read error: 54 (Connection reset by peer)) 13:38:45 provide both ^_^ 13:38:58 what exactly does 'postpone' do? 13:39:09 postpone = compile 13:39:13 and [compile] 13:39:17 in one word. 13:39:22 --- quit: Robert ("brb") 13:39:43 I'm gonna have RkF be "register"-based 13:40:06 arke, what is RkF? 13:40:16 arke, so what is [compile] then? :) 13:41:40 --- join: Robert (~snofs@c-185a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 13:41:50 slava: compile an immediate :P 13:42:07 --- quit: proteusguy (Read error: 110 (Connection timed out)) 13:42:35 --- quit: Nutssh ("Client exiting") 13:48:18 --- quit: arke (Read error: 104 (Connection reset by peer)) 13:48:21 --- join: arke_ (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 13:49:00 I decided to call the execute word a; -- jumps to address in A register. 13:49:56 heh, my 16-bit CPU has a branch instruction, but no return instruction :P 13:50:20 The Steamer16 CPU has only a conditional branch instruction. No subroutines, no returns, and not even a return stack. 13:51:05 Heh. 13:51:25 How many other instructions does it have, two? ;) 13:51:36 8 alltogether. 13:51:37 The Steamer16 has 7 other instructions. 13:51:51 It is the most MISC of the MISC architectures I've seen. 13:51:54 and a looping 3-depth stack :) 13:52:01 what's MISC mean? 13:52:08 But it's actually not optimized to run Forth; it's better at running C code than Forth code (believe it or not). 13:52:15 Minimal instruction set computer. 13:52:17 minimal instruction depth? 13:52:18 Minimum Instruction Set Computer. 13:52:25 aa. ok. 13:52:33 kc5tja: How fast does it run? 13:52:54 Robert: 16 to 30MHz; performance-wise it's about as fast as an 80386 at the same clock speeds. 13:53:56 Not too bad. 13:55:29 --- join: arke (~Chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 13:55:33 --- quit: arke_ (Read error: 104 (Connection reset by peer)) 13:55:58 --- quit: _proteus ("Leaving") 13:56:41 * kc5tja nods 13:56:52 It'll actually smoke a 386 if you could get it to blow through straight-line code. 13:57:03 But it's the simulated subroutines that slows it down. 13:57:43 How much power does it use? 13:57:54 Whatever a normal CPLD chip consumes. 13:57:59 It's implemented in programmable logic. 13:58:04 Oh. 13:58:46 Isn't it possible to make really low-power CPUs (while still being relatively fast) these days? 13:59:05 If you design it as an ASIC, yes. 13:59:13 ASIC? 13:59:20 The CPUs that Chandler quoted yesterday is a fine example. 13:59:38 Application-Specific Integrated Circuit -- e.g., you have ultimate control over individual transistors, where they get routed to, etc. 13:59:49 ASIC is a step above a custom-fab 13:59:54 but below an FPGA 13:59:58 Oh, okay. 14:00:07 The dual 1GHz MIPS-64 core draws only 5W. 14:00:17 Umm...no. 14:00:19 Just the opposite. 14:00:22 ASIC *is* custom fab. 14:00:43 Hifn produced highly integrated ASICs. 14:00:49 * kc5tja was responsible for testing them. :) 14:00:59 (which was fun. 1024-bit integer math coprocessors are *nice*.) 14:01:05 Heh. 14:01:10