00:00:00 --- log: started forth/09.12.06 00:02:20 --- quit: nighty^ ("Disappears in a puff of smoke") 00:51:08 --- join: Judofyr_ (n=Judofyr@c0E9CBF51.dhcp.bluecom.no) joined #forth 00:51:08 --- quit: Judofyr (Read error: 104 (Connection reset by peer)) 00:54:21 --- quit: Judofyr_ (Remote closed the connection) 01:16:31 Does anyone know where I can find some statistics on the "call vs. primitive" profile of well-factored Forth code? Obviously it will vary since different systems have different primitives, but any sort of guidance at all will interest me. 01:16:58 KipIngram: not sure what you mean. 01:17:14 Wow! De ja vu :P 01:17:16 secondaries vs primitives? 01:17:29 GeDaMo: "deju-vu again" 01:17:43 :D 01:18:01 i think he means what percentage of code is primitives vs. what percentage calls colon defs 01:18:07 ahh 01:18:32 well, if so - that's always varied by imp - and why an imp chose one or the other path 01:19:05 i can give you some statistics from my code: in my ITC system, about 20% of time is spent in EXIT ("SEMIS"), and about 15% is spent in DOCOL 01:19:31 that system does no inlining at all 01:19:57 also it doesn't have very many primitives (but not very few either) 01:20:24 which is this? (btw, kip: any forth build can be tweaked to retain and report info on this stuff - whacking the sources) 01:20:37 which system? old paflof. 01:20:50 pfe is supposed to be a production tool, and iirc, most of it is primitives. 01:21:24 this is on a very deeply pipelined machine though, so EXIT is very expensive 01:21:37 FIG forth was supposed to be portable, useful and an intro - so most of THAT was secondaries. 01:21:56 Yes - what segher said. 01:22:21 segher: thanks - that's good info. 01:22:29 --- quit: DrunkTomato () 01:22:42 any good system has mostly "secondaries". if your compiler is very good, it will inline most stuff though, so you do not actually pay 40%-50% overhead ;-P 01:23:09 it's closer to 20%-30% on most systems, fwiw 01:23:34 segher: I tend to differ in the view.. I figure "optimizing" and "inlining" is for later, if at all - I want stuff laid down well. Not tricky-cute ;-) 01:23:42 Yes. My system will have six five-bit primitives packed in every 32-bit cell. So any definition that has six or fewer primitives should certainly be inlined. 01:24:01 poppavic: inlining is completely transparent to the programmer 01:24:03 But yes, that will be for later. 01:24:29 kipingram: how do you handle literals? 01:24:44 Funny you should ask. I'll raise eyebrows here. 01:24:45 KipIngram: well, tathi's stuff did that with 6-bits@ - and i'm glaring at a nybble-variant which I doubt I'll bother to implement. 01:24:53 numbers, branches, and code addresses 01:25:08 Two primitives for literals: LIT and LIT... 01:25:39 LIT will take the next *five bit primitive* and treat it as a literal in the range from 0..31. 01:25:50 That's all I'll require for small literals like 0, 1, 2, etc. 01:26:05 LIT... will shift the top of stack left five bits and "and" the next cell in. 01:26:12 i do only 4 like that: 0, 1, -1, HIBIT 01:26:13 So large numbers will get built up five bits at a time. 01:26:51 and for negative you do a NEGATE or INVERT? 01:27:10 Yes, probably so. 1 NEGATE. 01:27:33 For me this has the advantage of getting *everything* into the primitive stream except for things that truly do relate to execution sequence. 01:27:43 -1 is used quite a lot, might want to make that cheaper 01:27:56 KipIngram: dcc offered 01:28:02 Yes, I was thinking of that the minute I described that two you. Probably will do that. 01:28:09 dcc? 01:28:19 so what about BRANCH and 0BRANCH ? those take one 5-bit imm? 01:28:26 Offering op-nybble.txt to KipIngram 01:28:37 In my system every 32-bit cell will contain either a call command, a jump command, or six five-bit primitives. 01:28:44 poppavic: just pastebin it, heh 01:29:09 heh, so your branches are really expensive 01:29:13 segher: yah.. Too broken to want the comments and laughs ;-) 01:29:14 I can specify the "six five-bit primitive" case in either of two ways - one implies a return after the primitives and one doesn't. 01:29:39 so pastebin it and /privmsg it to kipingram 01:29:42 Meaning they take up space? 01:29:52 yep 01:30:00 not just space, it's slower as well 01:30:31 Not necessarily, that's why I'm asking about profiling. Since I'm using the conditional exeution techniques we discussed a day or two ago I never do conditional branches. 01:30:55 never? ouch. that is expensive as well. 01:31:03 I can separate my system into a fetch unit and an execute unit. A lot of the calling, jumping, and returning, will happen in parallel with the execution of primitives already sent down the pipe. 01:31:16 say, BEGIN ... UNTIL 01:31:22 gahh 01:32:50 This sooo reminds me of those ancient FORTH Dimension debates, arguments - adn the c.l.f/c.l.c stuff 01:32:51 anyway, these are by far the most used words: call ret @ + 0branch branch 01:33:10 you want to have those fast no matter what 01:33:27 that's about 2/3th of the code dynamically 01:34:01 c.l.c? 01:34:11 segher: that's why I was asking such the other day, too - you'd think after all this time there would be *something* maintained, in particular re ANS "core" 01:34:17 comp-lang-c 01:34:59 segher: C is wandering a strange path into "the future".. Forths seem to be doing the same wandering. 01:35:01 what do they say about stack machine implementation? i'm confused 01:35:44 segher: oh, no - wrong context. I meant I've followed both once in awhile, and they all boil down to strange, esoteric debates. 01:35:57 heh sure 01:36:27 actually, RUMINT keeps whispering "stack machines are dead" - and I just sigh and nod.. 01:36:29 clf is good fun 01:36:47 rumint? who's that? 01:36:58 romor intelligence 01:37:00 rumor 01:37:31 I talk to guys "in the field" - and get some of the *whackiest* views and opinions. 01:37:41 x86 and arm are the two most used archs, in # programmers for them. both are stack machines :-P 01:39:14 well, the x86 can drop dead, for all of me.. I've not met the ARM. I've been told "they are not fast enough" - which doesn't tell me a lot. 01:39:48 Sorry guys - had to reboot. I didn't miss anything, though; my IRC really runs on my desktop and I ssh into it from the notebook. 01:40:30 I've spent time thinking about these issues you're bringing up. Not so much that I'm saying "I'm right and you're wrong," just enough to know that I want to try this. 01:41:02 KipIngram: I've no issues with anyone trying anything. These tincans and string get old. 01:41:09 ..too kany knots in the string now 01:41:13 many 01:41:19 arm is still very slow compared to e.g. powerpc (or mips even). for most embedded problems, smaller processors are a better fit -- but. arm socs are way way way cheap nowadays. 01:41:49 I understand that these approaches mean that some code could run badly. But I don't feel convinced that I can take responsibility for knowing how the hardware works and working with it to write code that will give me better performance that I could get with any other hardware / software combination. 01:42:18 My attitude is that I'm designing a *system*, where the hardware and software work together in a way that I take full responsibility for. 01:42:18 I like my ppc, and I'd imagine the arm speed is merely an age/dev issue. 01:42:23 kipingram: how will you handle BEGIN ... UNTIL or BEGIN ... WHILE ... REPEAT without conditional branches? 01:42:27 If some particular construct doesn't work well on this imp then I just won't use it. 01:42:55 poppavic: no, the arm arch actually limits lots of parallelism and pipelining, compared to e.g. powerpc 01:43:05 With conditional execution. The code will get passed through without doing anything. 01:43:16 they are _loops_ 01:43:21 you need a jump 01:43:45 segher: alas, I ain't gonna' get another ppc lappy unless I get used ;-) I keep hoping. 01:43:48 Unconditional jump from the bottom back to the top followed by "conditioned skipping" the last pass through. 01:43:57 so you will put a condition bit on an unconditional jump, perhaps? that's a conditional jump eh :-P 01:44:11 poppavic: i am typing on one now, heh 01:44:23 I love my lil' powerbook. 01:44:36 you have a 12"? 01:44:39 yah 01:44:45 Well, yes that's true, but it's the last of a sequence of skipped instructions, so I won't have any timing issues figuring that out. 01:44:47 shitty graphics, gets hot as well 01:44:54 other than that, yeah it's nice 01:44:56 I bought a refurb, when Ma' got bad and I was running up & down state 01:45:13 it keeps my left wrist/palm warm ;-) 01:45:48 In other words, it's not conditioned on some value I've just computed - I've known for some period of time whether I'm going to take that jump or not, so I've had time to pass that info back up to the fetch unit. 01:45:52 i have a 1.25GHz 15" and the first model tibook as well 01:46:14 imac G5 as desktop, and a bunch of imac G3s 01:46:16 But you did zero in on the one and only "back effect" from the execution unit to the fetch unit in my system. 01:46:29 i'll get a G4 cube soonish :-) 01:47:22 kipingram: how do you know "ahead of time" that it will/won't need to loop back? 01:47:23 KipIngram: I think yer working too hard for a synergistic effect w/o the evidences/proofs of the need, how, where and why 01:48:36 if you are worried that tight loops might need a pipeline bubble, you should keep a mini icache (pretty much like P4 trace cache) 01:48:39 the minimal-instruction-set stuff I've seen - from BF to tathi's and crc's and a few others - suggest you need a min of ops to get any else done. Fine and good - until you get that and start seeing patterns, you can't do much to "speed" it 01:48:46 all DSPs do it 01:49:01 Because the structure of the loop implies that on the last pass execution is switched off at the *top* of the loop and won't be switched back on until *after* the loop. 01:49:11 segher: oh, like the small loops in the onchip space. 01:49:44 poppavic: it won't have to go out to the system bus to get insns in a loop 01:50:08 do { .... ? leave (void)0; }while(1); 01:50:14 segher: right 01:50:16 kipingram: what, you always jump back and disable all insns until you are at the same spot again? how is that ever faster? 01:50:36 So as long as the execution unit has gotten the flag for the last pass onto the conditional stack before the fetch unit gets to the jump things will be fine. 01:51:12 that's exactly how a conditional jump works 01:51:23 I expect to be able to run the execution unit at a higher clock speed because of the simpler logic design required to do it this way. 01:51:36 i very much doubt it 01:51:44 but go ahead, prove me wrong :-) 01:51:57 I will or I won't, but I plan to try. 01:52:16 i call it "a waste of time", you can call it "research" :-) 01:52:24 I'll know soon enough if this works, and if I wind up not liking it, I'll change it. 01:52:32 You seem to feel awfully strongly about it. 01:52:37 nah 01:53:14 KipIngram: how much work have to done in researching the forth chips? 01:53:23 i know a thing or two about it, i very much doubt your scheme will work well 01:54:34 Ok. We'll see. 01:54:43 yeah :-) 01:55:00 I feel a bit like John Locke in "Lost." 01:55:14 His response was "don't tell me what I can't do." 01:55:50 KipIngram: fig-uk.org, forthwrite archive. 01:55:57 I will say, though, that these conversations always give me food for thought. 01:56:34 Alternatively, you can look at gforth's vmgen stats. 01:58:49 Hey, here's a thought. What if the jump at the bottom is truly unconditional - the fetch unit will always return to the top of the loop. But it will do so via a *call* instead of a jump? 01:58:57 That puts the address right after the loop on the return stack. 01:59:28 Now the code at the top that computes the flag will run, and will either pop the return stack and throw it away or do a return, depending on what needs to happen. 01:59:45 --- join: tathi (n=josh@dsl-216-227-91-166.fairpoint.net) joined #forth 02:00:18 hehe 02:00:28 I'll have to think on that some - will probably not work. 02:00:38 KipIngram: what makes you think CALL has an address? 02:00:47 I mean, it would "work", but probably won't keep me clear of sequencing issues. 02:01:18 What are you talking about? CALL has to CALL something. I specify CALL by having the MSB of the 32-bit cell be zero. 02:01:28 The 30 low order bits are the target. 02:01:39 [lit foobar; call; ... ] 02:02:05 CALL isn't a primitive for me in the same sense as other things. No five-bit primitive says "CALL". 02:02:27 The idea is that the sequencing unit has processed that all out before opcodes get put in the instruction queue. 02:02:49 kipingram: that scheme works, that's one way to implement DO ... LOOP :-) 02:03:47 segher: you keep using language-constructs.. I already know it's building up [un]conditional branches ;-) 02:04:31 LOOP does way more than that, you want to make it fast 02:04:43 segher: for fun, I like to catch the anti-goto folks and mention I want all high-level flow-control abolished for branch and zbranch instead ;-) 02:04:47 you can do a FOR ... NEXT isntead 02:05:02 huh? 02:05:48 all the forth conditionals/loops (except the counted loops) translate directly to branch/0branch 02:05:51 C and Forth.. Gotta' love it ;-) 02:06:10 segher: cool! 02:06:25 nice 02:11:29 segher: yeah.. I tinker more, anymore - I never get paid to code, and I've sorta' lost the drive to bother. 02:12:46 --- quit: ASau (Read error: 104 (Connection reset by peer)) 02:13:06 * crc has five jump instructions in his vm 02:13:39 crc: five flavors? I hope it's got vanilla and chocolate! 02:13:59 PoppaVic: unconditional, and four conditional forms 02:14:25 crc: I was teasing, I peeked. Besides, I remember 8080, z80, 6510 ;-) 02:19:45 hmm.. well, I thawed and fed the schmurp.. Looks like a bread-making day. 02:29:53 --- quit: pgas ("/quit") 02:36:16 the triple, nybble, octet "block" is an interesting idea, though. 02:52:15 crc: Yes, I noticed your five jump instructions. :-) 03:00:38 --- join: Maki (n=Maki@dynamic-78-30-155-247.adsl.eunet.rs) joined #forth 03:36:54 --- join: ASau (n=user@83.69.227.32) joined #forth 03:37:27 --- join: Snoopy_1711 (i=Snoopy_1@dslb-084-059-105-048.pools.arcor-ip.net) joined #forth 03:40:33 --- quit: kleinjt ("Lost terminal") 03:54:12 --- quit: Snoopy_1611 (Read error: 110 (Connection timed out)) 04:03:17 --- quit: Zarutian (Read error: 60 (Operation timed out)) 04:09:25 --- join: kar8nga (n=kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 04:32:33 --- join: Snoopy_1611 (i=Snoopy_1@dslb-084-059-105-048.pools.arcor-ip.net) joined #forth 04:49:32 --- quit: Snoopy_1711 (Read error: 110 (Connection timed out)) 05:27:49 --- quit: ASau (Read error: 104 (Connection reset by peer)) 05:45:52 --- quit: qFox (Read error: 54 (Connection reset by peer)) 06:03:36 --- quit: Maki ("Leaving") 06:18:34 --- quit: kar8nga (Remote closed the connection) 06:51:04 --- quit: GeDaMo ("Leaving.") 07:41:21 --- quit: uiu_ (Read error: 110 (Connection timed out)) 08:14:27 --- quit: segher ("This computer has gone to sleep") 08:18:56 --- join: kar8nga (n=kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 08:27:25 --- join: ASau (n=user@83.69.227.32) joined #forth 08:31:27 --- quit: tathi ("leaving") 08:49:56 --- quit: ASau (Read error: 54 (Connection reset by peer)) 08:57:06 --- join: ASau (n=user@83.69.227.32) joined #forth 09:12:44 --- quit: kar8nga (Read error: 104 (Connection reset by peer)) 09:24:43 --- quit: ASau (Read error: 104 (Connection reset by peer)) 13:02:01 --- quit: Al2O3 () 13:02:18 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 13:08:43 --- join: I440r (n=me@c-69-136-171-118.hsd1.in.comcast.net) joined #forth 14:12:22 --- join: dinya_ (n=Denis@94.51.208.17) joined #forth 14:35:54 --- join: DrunkTomato (n=DEDULO@ext-gw.wellcom.tomsk.ru) joined #forth 15:13:59 --- join: kar8nga (n=kar8nga@jol13-1-82-66-176-74.fbx.proxad.net) joined #forth 15:32:04 --- join: Judofyr (n=Judofyr@cC694BF51.dhcp.bluecom.no) joined #forth 15:33:31 --- quit: kar8nga (Remote closed the connection) 15:34:23 --- quit: foxes (Remote closed the connection) 15:40:42 --- join: foxes (i=flash@221.220.46.126) joined #forth 15:45:28 --- quit: foxes (Remote closed the connection) 16:12:59 --- join: ASau (n=user@host182-231-msk.microtest.ru) joined #forth 16:21:25 --- quit: PoppaVic (Client Quit) 17:01:01 --- quit: zbrown (verne.freenode.net irc.freenode.net) 17:01:10 --- join: zbrown (n=suifur@rufius.xen.prgmr.com) joined #forth 17:13:47 --- quit: Al2O3 (Read error: 110 (Connection timed out)) 17:34:04 --- quit: DrunkTomato () 17:35:05 --- join: cataska (n=cataska@210.64.6.233) joined #forth 18:01:11 --- join: H4ns (n=Hans@p57BBAA13.dip0.t-ipconnect.de) joined #forth 18:07:32 --- join: Al2O3 (n=Al2O3@c-75-70-11-191.hsd1.co.comcast.net) joined #forth 19:06:17 --- join: segher (n=segher@84-105-60-153.cable.quicknet.nl) joined #forth 19:15:22 --- join: |dinya_| (n=Denis@90.151.34.166) joined #forth 19:32:46 --- quit: dinya_ (Read error: 110 (Connection timed out)) 20:26:51 --- join: tathi (n=josh@dsl-216-227-91-166.fairpoint.net) joined #forth 21:39:52 --- part: H4ns left #forth 22:05:22 --- join: foxes (i=flash@221.220.46.126) joined #forth 22:17:14 --- join: Al2O3_ (n=Al2O3@c-71-196-185-65.hsd1.co.comcast.net) joined #forth 22:17:57 --- quit: Al2O3 (Read error: 60 (Operation timed out)) 22:18:12 --- nick: Al2O3_ -> Al2O3 22:27:09 --- quit: ASau (Read error: 54 (Connection reset by peer)) 22:41:51 --- join: DrunkTomato (n=DEDULO@ext-gw.wellcom.tomsk.ru) joined #forth 23:03:59 --- quit: DrunkTomato () 23:59:59 --- log: ended forth/09.12.06