00:00:00 --- log: started forth/19.05.15 00:00:26 --- quit: proteusguy (Ping timeout: 246 seconds) 00:12:55 --- join: proteusguy (~proteusgu@mx-ll-14.207.208-30.dynamic.3bb.co.th) joined #forth 00:12:55 --- mode: ChanServ set +v proteusguy 01:19:08 --- quit: MrMobius (Read error: Connection reset by peer) 01:27:30 --- quit: proteusguy (Ping timeout: 252 seconds) 01:29:18 --- quit: chunkypuffs (Quit: ZNC 1.7.1 - https://znc.in) 01:30:57 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 02:04:50 --- quit: ashirase (Ping timeout: 255 seconds) 02:06:07 --- join: proteusguy (~proteusgu@cm-58-10-154-216.revip7.asianet.co.th) joined #forth 02:06:08 --- mode: ChanServ set +v proteusguy 02:08:57 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:38:48 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 02:41:02 --- quit: pierpal (Quit: Poof) 02:41:21 --- join: pierpal (~pierpal@host202-151-dynamic.56-79-r.retail.telecomitalia.it) joined #forth 02:41:32 hi 02:55:22 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 03:05:01 --- quit: dddddd (Ping timeout: 258 seconds) 03:09:57 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:34:28 thanks ttmrichter 04:40:10 --- quit: Rickta59 (Quit: leaving) 05:10:54 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 05:40:39 --- quit: pierpal (Remote host closed the connection) 06:03:20 --- quit: jpsamaroo (Ping timeout: 258 seconds) 07:02:00 --- join: tabemann_ (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 07:02:07 --- quit: tabemann (Ping timeout: 250 seconds) 07:33:48 --- quit: tabemann_ (Ping timeout: 258 seconds) 07:48:44 --- quit: dave0 (Quit: dave's not here) 08:16:47 OK, I just pondered something I never see mentioned.. I know forths have a "standard min" depth of 16 cells, but.. It occurs to me: isn't this really something relative to the number of registers (and their size)? 08:25:41 why is that? 08:26:46 well, for example: I am currently writing the RX isr's and such, first few tries was shoveling a TON of registers to the stack. Enough to fill the 16-slot stack 08:27:30 I can clean that up, but it's apparent that the 16-cell size is meant for the FORTH - not an underlying interrupt or 3 08:27:46 i think the intention is that you use the stack as your work area and not for storage. if you need to save some values, you use variables 08:29:40 since the ISR is "working", it's using the stack as-intended. Granted, I have to go back thru the generated code: Even if the registers are designated as "free" to any forth word, the ISR is interrupting anything - and thus really needs to preserve content. 08:34:43 I think the easiest answer is to double the size of the HW/RS stack - but, yeah. I rarely see anyone speaking of the stack size decisions. 08:35:12 you're actually manipulating 16 values at once? 08:35:49 or is it that you're saving register states so that you can restore them before you return from the isr? 08:36:00 No, it's using about 4 or 6 registers and preserving content on entry, doing it's job (adding byte to ring), and then restoring them all 08:36:35 yeah, so i would say the "forthy" thing to do would be to save state in memory, not on the stack 08:37:58 I'm pretty sure that ends up being pricey. You'd need to point to Yet Another Buffer Area (saving the pointer-regs first) and move stuff that way 08:38:22 forth is pricey in my experience 08:38:42 ..I dunno as it matters if it uses the RS/hw stack, since it's never going to be noticed by the forth words 09:09:41 i will say that it always seemed to me like the return stack should be deeper than the parameter stack 09:09:57 and if that's the case, then you can use it for stashing values 09:10:14 DOne & dusted 09:15:00 --- quit: xek (Ping timeout: 252 seconds) 09:15:40 --- join: john_metcalf (~digital_w@host86-167-209-202.range86-167.btcentralplus.com) joined #forth 09:21:10 PoppaVic: re: stack size decisions: I configure my VM to either have identical depths (when memory isn't a concern) or to have the address stack be 3-4x the depth of the data stack (when memory is more limited). 09:22:46 Rebuilding my image takes 21 spaces on the data stack and 76 on the address stack. I normally configure the address stack to be at least 256 cells, giving reasonable headroom for actual applications. 09:29:02 that sorta' maks sense, thanks 09:29:21 Was there a calculation/observation you applied to determine this? 09:30:05 (it sounds like you ran a build-cycle that just tracked greatest-depth, which most folks won't do) 09:34:32 In my case, I am observing that gcc translates my simple-c ISR into 8 pushes/pops, (which is fair as we are saving state, saving the ram pointer-pair, etc). This is about 1/4 the registers available - and likely 2 or more than handtuning requires. But, in my case: the stacks are 1/2 the size of registers to start with - doable with forth, but not with ISRS - so I am watching and thinking of 09:34:32 half-again-larger or double for hw stack. 09:39:23 PoppaVic: I have a special copy of my VM that tracks stack depth and some other metrics 09:40:01 crc: certainly.. I think I've memories of diddling FIG forth for that - and word-use-counts - from the dark-ages 09:41:01 My address stack depth is probably more than most forths would need. I have conditional calls, but not conditional jumps, so any conditional execution will add an address to the stack 09:41:13 crc: I just ponder if it'd be useful to think in terms of "X*registers*bytes-per-cell" or similar for designs 09:43:57 crc: interestingly, I seem to recall that forth implementations actually use LESS stack than the assembler will need - and I seem to recall that our "words" rarely dive deeper than maybe 3 nesting-levels 09:45:04 (the former is likely due to pushing arguments instead of requiring everyone to push a dozen registers per nesting) 09:46:24 my forth is not conventional, and lots of factoring leads to greater address stack use 09:47:02 Understood. Kip's variant is showing me an awfully interesting idea thus. Looking forward to a copy to try 09:47:53 I still notice he's not really exploiting the RS depths - just using it to do a lot of conditionals. 10:07:06 Wow, I just tried to benchmark a simple, double-nested loop with RETRO vs. gforth. 10:08:03 Doing 10'000 x 1000 iterations is 2.3 seconds with RETRO and 0.04 with gforth. 10:09:32 yes 10:09:44 10'000x10'000 is 0.22-0.23s with gforth and ... 22.9 seconds with RETRO. 10:10:05 gforth is a monster of C and asm that compiles super-instructions, asm and pcode 10:12:31 john_cephalopoda: keep in mind: retro is running on an emulated MISC cpu with 30 instructions; gforth runs on the physical processor and does much more optimizations 10:13:04 I actually get 0.2 seconds with pforth. 10:14:12 Weird that pforth is faster than gforth in this case... 10:14:56 But explains why my mandelbrot set viewer is noticably slower with retro. 10:15:16 which loop form are you using with retro? 10:16:48 [] times loops. 10:17:08 With gforth/pforth, I am using DO ... LOOP 10:25:04 Huh, I think "while" loops might be more efficient... 10:25:33 can you try again, using this definition for `times`: :times (nq-) [ swap repeat 0; #1 - push dup push call pop pop again ] call drop ; 10:28:57 7.984 seconds. 10:30:57 The while loop implementation ( https://bpaste.net/show/4fc34c4e4016 ) takes 11.8 seconds 10:32:30 one more to test: :times (nq-) [ swap repeat 0; `33886721 `1 `2053 `1542 again ] call drop ; 10:33:10 (this one inlines the nga instruction bundles directly, it should be a little faster than the previous test one) 10:33:34 4.75 seconds. 10:34:41 ok, I'll update the development build to use this instead 10:35:23 Hm, what about the times word? 10:35:32 Could it be improved in a similar way? 10:36:46 maybe. I'll take a look shortly if it stays slow (at work currently) 10:59:15 john_cephalopoda: http://forth.works/1143186fb396c05944cc639837a109f4 11:35:03 --- quit: gravicappa (Ping timeout: 246 seconds) 13:15:18 Hmm, I used while for the most important loop in my mandelbrot set viewer, so the improvement in times doesn't make a difference. 13:32:51 :while (q-) [ repeat `525570 `1639430 drop again ] call drop ; 13:35:16 this may be a bit faster. saves a call/return per loop, and reduces the number of needed instructions per loop from 11 to 7 13:49:51 * crc commits this and a similar version of `until` to the development branch 13:59:42 --- quit: Keshl (Read error: Connection reset by peer) 14:00:00 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 14:03:24 3.52 to 3.35 seconds for 10000 iterations with ascii. 14:05:52 Or with 100'000: 32 vs 34 seconds. 14:06:12 Not a giant gain, but not bad for one small change. 14:13:05 how is optimization usually implemented for things like swiftX? 14:13:11 is it typically a peephole type of thing? 14:13:49 or will they use some kind of IL maybe in SSA form... or is this not a very forthy thing to do? 14:15:54 gaze___: It looks like they got an optimizer built-in. 14:16:21 well, I mean how did they likely do it? 14:17:51 No clue. 14:18:26 But it appears to work a bit differently from most Forth systems, which don't optimize much in order to be simpler. 14:28:08 --- quit: john_metcalf (Quit: http://corewar.co.uk) 14:43:47 Hmm, with the while optimisation, my Mandelbrot viewer gets about 7% faster 15:07:30 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth 16:20:28 I'm not sure I can make it faster without resorting to trickery (I have a build of the vm that intercepts calls to certain functions and some opcode bundles and handles the functionality directly) 16:42:44 --- quit: john_cephalopoda (Ping timeout: 258 seconds) 16:55:43 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 16:56:03 hi 16:56:17 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:29:07 --- join: tabemann (~tabemann@ip-64-134-149-246.public.wayport.net) joined #forth 17:33:18 --- quit: tabemann (Ping timeout: 244 seconds) 17:37:52 --- quit: xek (Ping timeout: 258 seconds) 17:54:53 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 19:13:46 --- quit: pareidolia_ (Ping timeout: 252 seconds) 19:35:43 --- join: pareidolia (~pareidoli@87.213.124.143) joined #forth 20:01:15 --- quit: tabemann (Ping timeout: 258 seconds) 20:01:19 --- quit: dave0 (Quit: dave's not here) 20:09:24 --- quit: dddddd (Remote host closed the connection) 20:10:13 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:10:48 --- quit: Keshl (Read error: Connection reset by peer) 20:20:46 --- join: Keshl__ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:21:27 --- quit: Keshl_ (Read error: Connection reset by peer) 20:21:35 --- quit: jedb (Remote host closed the connection) 20:24:56 --- join: Keshl___ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:25:02 --- quit: Keshl__ (Read error: Connection reset by peer) 20:30:09 --- join: jedb (~jedb@103.254.153.113) joined #forth 20:32:17 --- quit: Keshl___ (Read error: Connection reset by peer) 20:32:28 --- join: Keshl___ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:41:43 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 20:42:12 --- quit: Keshl___ (Read error: Connection reset by peer) 20:43:02 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth 21:02:31 --- join: Keshl_ (~Purple@207.44.75.198.res-cmts.gld.ptd.net) joined #forth 21:04:05 --- quit: Keshl (Ping timeout: 250 seconds) 21:07:41 --- join: gravicappa (~gravicapp@h109-187-22-102.dyn.bashtel.ru) joined #forth 21:09:54 --- join: Keshl__ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 21:10:48 --- quit: Keshl_ (Ping timeout: 246 seconds) 21:40:26 --- quit: Keshl__ (Quit: Konversation terminated!) 21:43:40 --- join: pierpal (~pierpal@host103-244-dynamic.55-79-r.retail.telecomitalia.it) joined #forth 21:56:08 --- join: Keshl (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 22:00:13 crc: One of the things I like best about Forth is that you CAN resort to trickery at need without breaking the language. 23:54:50 --- join: xek (~xek@user-5-173-137-10.play-internet.pl) joined #forth 23:59:59 --- log: ended forth/19.05.15