00:00:00 --- log: started forth/19.05.08 00:05:41 --- quit: proteusguy (Ping timeout: 246 seconds) 00:21:54 --- join: proteusguy (~proteusgu@mx-ll-183.89.213-239.dynamic.3bb.co.th) joined #forth 00:21:54 --- mode: ChanServ set +v proteusguy 00:31:44 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 00:36:17 --- quit: pierpal (Ping timeout: 248 seconds) 01:00:23 --- quit: smokeink (Remote host closed the connection) 01:00:44 --- join: smokeink (~smokeink@118.131.144.140) joined #forth 01:15:43 How are yall 01:19:27 Hi WilhelmVonW, all good. 01:24:22 all is well 01:24:44 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 01:41:08 good to hear 01:41:20 writing about some Forth history for this report today 01:41:33 Cool 01:41:42 hopefully my professors enjoy threading approaches as much as I do 01:41:45 :^) 01:43:59 Interpretation and Instruction Path Coprocessing (Debaere and Van Campenhout) has good descriptions and comparisons of the various threading approaches 01:45:49 Chapter 2 01:47:51 Awesome, a reference 01:47:53 cheers 01:48:08 np 02:34:09 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 02:38:19 --- quit: pierpal (Ping timeout: 245 seconds) 02:45:44 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 03:07:39 rdrop-exit, looks like a remarkably interesting book. 03:53:29 It clearly explains intermediate representations (circa late 80s) and some cool ideas on specialized coprocessors for boosting threaded-code interpretation. 03:58:28 I've had it since the early 90s, I think I read through it twice the day I got it. 04:02:35 Although I should caution that it is short, and half of is an explanation of what most Forthers already know. 04:04:01 But unlike most Forth books it focuses on the low level aspects of interpretation. 04:09:41 --- quit: proteusguy (Ping timeout: 258 seconds) 04:09:42 --- join: proteus-guy (~proteusgu@mx-ll-183.89.213-239.dynamic.3bb.co.th) joined #forth 04:09:42 --- mode: ChanServ set +v proteus-guy 04:26:33 --- quit: proteus-guy (Remote host closed the connection) 05:04:44 --- join: proteusguy (~proteusgu@cm-58-10-154-216.revip7.asianet.co.th) joined #forth 05:04:44 --- mode: ChanServ set +v proteusguy 06:02:52 Where is this book available? 06:37:38 --- quit: smokeink (Read error: Connection reset by peer) 06:50:52 I bought mine almost 30 years ago from Computer Literacy in Sunnyvale. Try Powell's I guess. 07:29:47 --- quit: travisb (Ping timeout: 258 seconds) 07:47:25 Reading through The Art of Computer Programming Volume 1 3rd Edition, it seems that a Forth is definitely possible 07:47:35 Albeit the stack would have to be simulated 07:47:59 Since the MIX machine lacks stacks (the examples in the book use self-modifying code to emulate subroutines) 07:48:15 Knuth mentions that this was popular back in the 70s and 80s 07:51:52 Wheeler jumps everywhere! 07:54:11 You could do it on MMIX instead 07:54:19 https://en.wikipedia.org/wiki/MMIX 07:59:13 rdrop-exit: right, i'll look into that later 07:59:30 I wonder if he would get around to a new edition using MMIX 07:59:50 Then again it would be better if the next volumes were published 08:04:42 He uses it in the volume 4 fascicles 08:10:57 I have 0-4, not sure what others have been published since 08:44:34 rdrop-exit: I also have a hardcopy of "Interpretation and Instruction Path Coprocessing (Debaere and Van Campenhout)" really deep reference on threaded code. I also really like the idea of a coprocessor sitting in the instruction path not just the usual data path coprocessor. 08:44:34 ttmrichter: Used hardcover copies of the book have since gotten super-max expensive on amazon since I bought a copy. Although, the MIT press book store staff told me they do print on demand for older books. 09:21:59 --- quit: rdrop-exit (Quit: Lost terminal) 09:33:47 --- join: john_metcalf (~digital_w@host86-176-134-77.range86-176.btcentralplus.com) joined #forth 10:21:13 pointfree, what does the coprocessor sitting in the instruction path do? 10:30:44 --- quit: pierpal (Read error: Connection reset by peer) 10:44:34 --- quit: Zarutian (Read error: Connection reset by peer) 10:45:05 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 10:59:19 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 11:56:49 --- quit: gravicappa (Ping timeout: 248 seconds) 12:05:19 https://dpaste.de/Y6Cs is that a bad way to use a stack value multiple times in a function? 12:05:32 I dup it before i use it in a case 12:10:19 Hey Rickta59 12:10:33 hi 12:12:25 Oh, interesting, I didn't know about the %1010 syntax before. 12:14:37 What you are doing looks perfectly fine. 12:15:59 The stack exists for that exact purpose :þ 12:20:41 k 12:20:43 thanks 12:20:58 is that how you would do it? 12:26:28 Yup, that's how I'd do it. 12:27:00 Here's some code I've written, a Mandelbrot viewer in Forth: http://thecutecuttlefish.org/mandelbrot.html 12:27:36 http://ix.io/1IqX 12:27:50 I liked some of this when I wrote it 12:28:19 In the word "CALCULATE_MB", I leave the X and Y value on the stack and 2DUP them, do some operations on them and then grab the original values again, when I need them. 12:32:28 proteusguy: It can do things like prefetch instructions and inline native code while the cpu is executing so that the cpu only sees a stream of native code (no long arrays of word addresses in the cpu). It's not branch prediction so much as a coprocessor that handles threaded code while the cpu executes native code. 12:32:28 I remember talking with Mat4 (?) about the idea of a memory controller/address decoder with which addressing is dynamically compressed using Boolean logic minimization or similar instead of using straight random access all the time. Perhaps a similar dynamic instruction path could be done with a coprocessor like this. 12:32:28 Zarutian pointed out that the inner interpreter is so simple it could be implemented as an instruction path coprocessor with a simple combinational circuit. 12:32:28 KipIngram pointed out that on a SoC the memory is already very close to the cpu so perhaps there is not much performance to be gained these days with a discrete instruction path coprocessor. 12:32:28 For off-chip peripherals with an spi, i2c command set it could make sense in a forth where sensors can compile runnable code, e.g. http://www.0xff.in/bin/AndreasWagner-parse-time-execution.pdf ( the method in my slides is no longer how I'm doing it) 12:32:28 Hey, how about a little sixel coprocessor that sits between the uart and the cpu. Just a thought. 12:47:50 https://dl.acm.org/citation.cfm?doid=339647.339694 "Instruction path coprocessors" 12:51:14 SVFIG has a booth at Bay Area Maker Faire ( booth #69322 ) ! Is anyone here going? 12:53:29 *69332 https://makerfaire.com/maker/entry/69332/ 13:14:59 --- quit: the_cuckoo (Ping timeout: 250 seconds) 13:15:25 --- quit: lchvdlch (Ping timeout: 250 seconds) 13:15:25 --- quit: KipIngram (Ping timeout: 250 seconds) 13:15:25 --- quit: cheater (Ping timeout: 250 seconds) 13:15:42 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth 13:15:44 --- join: the_cuckoo (~charlie@d51A50AE9.access.telenet.be) joined #forth 13:15:51 --- quit: proteusguy (Ping timeout: 250 seconds) 13:15:51 --- quit: APic (Ping timeout: 250 seconds) 13:16:06 --- nick: KipIngram -> Guest29438 13:17:50 --- join: cheater (~cheater@unaffiliated/cheater) joined #forth 13:20:01 --- quit: reepca (Ping timeout: 248 seconds) 13:20:33 --- join: lchvdlch (~nestr0@191.98.151.137) joined #forth 13:28:18 --- join: proteusguy (~proteusgu@cm-58-10-154-216.revip7.asianet.co.th) joined #forth 13:28:18 --- mode: ChanServ set +v proteusguy 13:28:57 --- join: APic (apic@apic.name) joined #forth 14:02:10 --- nick: Guest29438 -> KipIngram 14:02:22 --- mode: ChanServ set +v KipIngram 14:07:11 --- join: reepca (~user@208.89.170.37) joined #forth 14:36:57 So, a while back I had this idea that I could use my frame pointer system to provide a way for child threads to operate on data directly in the parent's stack. 14:37:02 Looked very nice. 14:37:43 But a few days ago I read an article on false sharing and realized that that would very likely mean I'd have two or more cores contending over that parent stack; might wind up thrashing cache lines amongst them. 14:37:50 Might get WORSE performance in the end. 14:37:57 But I still really like the general idea. 14:38:15 So now I'm thinking that I want to accentuate my data stack with some words that will let me manage it in terms of cache lines. 14:38:34 When I'm going to send a cache line to another core to work on, I'll leave that cache line VACANT except for the parameters of that work. 14:38:44 And the child core can send results back in that same cache line. 14:38:46 Or lines. 14:38:56 Anyway, make it so that I never have more than one core operating on any one cache line. 14:39:25 I haven't worked out a specific approach yet. 14:39:38 But it brings kind of a two-dimensional nature to the data stack. 14:40:02 I want it to work unchanged for non-parallel work (I just wouldn't use any of the new words). 15:34:53 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 15:35:55 hi 15:36:27 yo 15:37:15 so i feel happy i wrote a chunk of mecrisp-stellaris forth that actually seems to work 15:37:35 https://github.com/RickKimball/mecrisp-stellaris/blob/nucelo-f030r8/mecrisp-stellaris-source/stm32f030r8-ra/mhz.fs 15:39:20 does this channel mainly talk about implement forth more than fort? 16:50:09 --- quit: john_cephalopoda (Ping timeout: 248 seconds) 17:04:09 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:05:50 --- join: smokeink (~smokeink@118.131.144.140) joined #forth 17:15:13 --- join: X-Scale` (~ARM@228.24.108.93.rev.vodafone.pt) joined #forth 17:15:49 --- quit: smokeink (Remote host closed the connection) 17:17:03 --- quit: X-Scale (Ping timeout: 258 seconds) 17:17:03 --- nick: X-Scale` -> X-Scale 17:36:27 --- quit: dave0 (Quit: dave's not here) 17:51:05 --- join: X-Scale` (~ARM@71.40.54.77.rev.vodafone.pt) joined #forth 17:52:29 --- quit: X-Scale (Ping timeout: 246 seconds) 17:52:29 --- nick: X-Scale` -> X-Scale 18:08:44 --- join: travisb (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 18:23:49 --- quit: chunkypuffs (Quit: ZNC 1.7.1 - https://znc.in) 18:24:19 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 18:45:25 Rickta59: It's the dominant talk only because there's quite a few Forth implementers here. 19:02:57 --- quit: dddddd (Remote host closed the connection) 20:19:34 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 20:20:17 hi 20:33:49 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 20:34:49 No difference really, adapt and extend 20:35:12 Good morning Forthers and all ships at sea 20:39:31 morning 20:41:13 Hi presiden 20:41:29 hello rdrop-exit 20:42:11 here your exit, you rdrop it 20:42:25 done, thanks :) 20:45:59 --- join: gravicappa (~gravicapp@h109-187-242-147.dyn.bashtel.ru) joined #forth 21:07:10 --- quit: pierpal (Quit: Poof) 21:07:29 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 21:09:52 --- quit: Keshl (Read error: Connection reset by peer) 21:09:57 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 22:00:42 --- quit: pierpal (Read error: Connection reset by peer) 22:00:59 --- join: pierpal (~pierpal@host57-236-dynamic.22-79-r.retail.telecomitalia.it) joined #forth 23:16:35 pointfree, instruction coprocessor does sound fascinating. 23:22:41 --- quit: proteusguy (Ping timeout: 248 seconds) 23:51:33 Rickta59: http://jeelabs.org/2016/02/dive-into-forth/ ? 23:52:12 Is it interesting? 23:59:59 --- log: ended forth/19.05.08