00:00:00 --- log: started forth/21.02.16 00:26:07 --- join: fiddlerwoaroof_ joined #forth 00:28:48 --- quit: rpcope (Ping timeout: 240 seconds) 00:29:01 --- join: rpcope joined #forth 00:30:56 --- quit: fiddlerwoaroof (Ping timeout: 258 seconds) 00:48:52 --- join: dave0 joined #forth 00:54:48 --- join: xek joined #forth 02:21:49 --- join: dysprosaic joined #forth 03:07:27 --- quit: iyzsong (Ping timeout: 240 seconds) 03:08:57 --- join: iyzsong joined #forth 03:09:01 --- quit: cantstanya (Ping timeout: 268 seconds) 03:12:36 --- join: cantstanya joined #forth 03:21:15 --- quit: dysprosaic (Ping timeout: 256 seconds) 05:46:01 --- join: nitrix joined #forth 05:46:33 Hello. I have a curious itch to scratch and I think some of you may know the answer so I'm giving it a try: Does threaded code (forth-like) execute slower or faster than the alternate calling conventions? 05:46:41 I haven't managed to find reliable information, especially with caching. If anyone knows, thanks in advance x] 05:47:09 oh shit it's nitrix ! 05:47:14 hi nitrix 05:47:29 dave0, I'm joining the dark side, I think. 05:47:30 i don't know sorry, i'm a newbie 05:48:54 nitrix: Is the hypothesis something like if the code is smaller because of the threading model it might have less cache penalty? 05:50:57 veltas, I suppose so, yeah. The routines are pointers to codewords and forth words are just a bunch of those, so I'm guessing forth code has a really high code density. 05:51:47 --- quit: hosewiejacke (Ping timeout: 240 seconds) 05:52:49 I don't know but I'm assuming it is generally slower as basically all mature x86 forths generate optimised machine code 05:52:57 --- join: Zarutian_HTC joined #forth 05:54:47 --- join: elioat joined #forth 05:55:17 Does the "optimised machine code" does register allocation? 05:57:41 I think so, because forth is stack-based, a lot of existing understanding on e.g. JIT optimisation applies because those tend to target stack-based bytecodes 05:58:10 In some extreme scenario I suppose a threaded forth could keep all native code in the CPU's i-cache, producing churn in the d-cache only. Ideally that's using some non-FIG memory layout though (which intersperses code, headers and strings, making the cache situation a bit messy) 05:59:08 It's a probably an extreme scenario where the bottlenecks don't already fit in cache, unless they're not very localised in which case they wouldn't be localised in threaded code necessarily either 05:59:51 --- join: hosewiejacke joined #forth 06:12:32 hi, I'm a complete newbie, I'm confused by the problem in starting forth chapter 2 to implement 3DUP 06:12:52 because all the stack operations I know only operate on the top 3 items of the stack, so once I have duplicated 2 of the values I can no longer reach the third 06:14:08 nihilazo: know of the R> and >R words? 06:14:22 they haven't come up yet in the book 06:16:58 have you read chapter 2 to the end? /me trying to recall if >R and R> are introduced there or not 06:19:12 they don't seem to be there, I'm reading the web version 06:25:10 nihilazo: what about PICK? 06:25:30 nope 06:25:57 I have swap, dup, over, rot, drop, 2swap, 2dup, 2over, and 2drop 06:26:14 I assume I am intented to use 2over etc to implement 3dup 06:27:59 i can think of one combination that will do it, do you want it? 06:28:39 --- nick: jedb_ -> jedb 06:29:47 sure 06:29:55 DUP 2OVER ROT 06:38:25 --- quit: dave0 (Quit: dave's not here) 06:38:25 inode: never assume that PICK is available or cheap. On Harris RTX2010 it isnt cheap because the stacks live in seperste memory devices seperated from program/working memory 06:40:07 Zarutian_HTC: thanks for the tip, but i'll worry about that when you send me an RTX2010 to play with ;) 06:42:01 eh, it also makes it faster on JITing Forth runtimes as there is no dynamic index into data dependency 06:44:01 fair enough, but to help someone with a book problem, i'm pretty sure a dirty hack for 3DUP like 2 PICK 2 PICK 2 PICK isn't going to kill anyone :) 06:44:05 when it says 2dup is (d -- d d), I guess that is a pair of numbers on the stack rather than a single one 06:44:31 I think that might be my confusion, I was reading those stack effects the same way as ( n -- n n) for dup and assuming each thing there was only one value 06:52:35 re register allocation, optimizing forths like SwiftForth only use a subset of the registers and the rest lay dormant or you can use them if you want to drop into assembly 06:53:30 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 06:53:44 --- join: Zarutian_HTC joined #forth 07:39:32 --- join: mikke|72 joined #forth 07:41:58 --- quit: Zarutian_HTC (Ping timeout: 240 seconds) 07:56:51 --- part: mikke|72 left #forth 07:59:04 --- join: flashforth joined #forth 08:07:37 --- join: Zarutian_HTC joined #forth 08:10:55 --- quit: zolk3ri (Remote host closed the connection) 08:15:15 --- quit: hosewiejacke (Ping timeout: 260 seconds) 08:21:07 --- join: zolk3ri joined #forth 08:39:36 nitrix, typically threaded code will not run quite as fast as optimized linear code written for that processor. Note that most processors are register based rather than stack based and can't benefit as much due to their architecture. That said - thought out in the right environment, threaded code can sometimes beat what "normal" calling conventions may come up with but you've really gotta be aware of your architecture and 08:39:36 looking out for opportunities. To me - it's more of a matter of speed of development and assurances that my code is correct because it's so much simpler. Forth can out perform languages like python & ruby fairly easily so it's rarely an issue in terms of performance. 08:41:53 --- quit: elioat (Quit: elioat) 09:03:30 --- join: elioat joined #forth 09:16:09 --- quit: Zarutian_HTC (Remote host closed the connection) 09:30:21 --- join: Zarutian_HTC joined #forth 09:37:08 --- join: hosewiejacke joined #forth 09:50:12 --- quit: zolk3ri (Remote host closed the connection) 09:55:24 --- join: zolk3ri joined #forth 09:58:54 --- quit: elioat (Quit: elioat) 10:18:58 --- join: f-a joined #forth 10:31:29 --- quit: zolk3ri (Remote host closed the connection) 10:33:28 --- join: zolk3ri joined #forth 10:36:58 --- quit: gravicappa (Ping timeout: 240 seconds) 10:39:51 --- join: gravicappa joined #forth 10:55:32 --- quit: hosewiejacke (Quit: Leaving) 10:56:57 --- join: elioat joined #forth 11:02:31 --- quit: zolk3ri (Remote host closed the connection) 11:02:44 --- join: zolk3ri joined #forth 11:32:37 --- quit: f-a (Ping timeout: 256 seconds) 11:34:19 --- join: f-a joined #forth 11:34:57 I am writing a simple «test» word, to test words 11:35:12 as now it simply is : test ' execute = ; 11:35:37 is there a way to print the name of the word I am testing? 11:35:42 ideally I would like 11:35:58 9 3 square-me "square-me works!" 11:36:07 10 3 square-me "square-me does *not* work!" 11:41:35 f-a: look into how the ' word works 11:42:04 with see ' 11:50:37 f-a: i think the word `word' grabs the next word from the input stream and returns it to you as a string 11:52:03 super 11:52:12 f-a: double checking that... 11:55:36 f-a: I think `parse-name' is what I was looking for, a.k.a., `parse-word' 11:56:17 at least, those are the ones in gforth 11:56:29 indeed indeed, I should have checked that with se- yes me too using gforth 11:57:46 f-a: I thought I remember learning something a little different in The Forth Handbook, but the Handbook is not with me here at work 11:58:06 --- join: X-Scale` joined #forth 11:59:07 --- quit: X-Scale (Ping timeout: 264 seconds) 11:59:08 --- nick: X-Scale` -> X-Scale 12:59:32 --- quit: gravicappa (Ping timeout: 272 seconds) 13:08:08 * Zarutian_HTC has only ever used eforth and openfirmware forth 13:57:06 f-a: How do you know if a word works or not? 13:57:36 Oh right I see now you give a desired result then the input 13:58:29 oh yes I should have described the problem more accurately 13:58:43 yeah I would like a "Dear Sir/Madam, your word XYZ fails the test" 13:59:21 No it's my fault I'm trying to do two things at once 14:01:07 --- quit: elioat (Quit: elioat) 14:10:23 f-a: : test bl word dup >r find drop execute r> count type = if ." works!" else ." does *not* work!" then ; 14:10:48 9 3 test squared \ squared works! 14:10:59 10 3 test squared \ squared does *not* work! 14:13:24 super useful, I am going to `see` all of them words 14:13:30 f-a: Also have a look at the forth200x tests, because it's more flexible than this and looks better. https://github.com/gerryjackson/forth2012-test-suite 14:13:39 thanks 14:13:48 e.g. T{ 1 0 AND -> 0 }T 14:13:55 ohhh 14:14:06 Checks that after "1 0 AND" you get 0 on stack and nothing else for example 14:15:53 bl is… ? 14:15:59 ' ' 14:15:59 see bl 14:15:59 32 Constant bl 14:16:13 `see` is sometimes a bit uninformative without comments 14:16:14 thanks 14:16:45 Check out forth-standard.org 14:18:45 f-a: Which forth are you using? 14:19:58 --- quit: xek (Ping timeout: 272 seconds) 14:20:57 Funny how the BL word has so much activity on it 14:21:00 gforth, veltas 14:22:27 f-a: https://gforth.org/ https://gforth.org/manual/Word-Index.html#Word-Index 14:22:48 That website has I believe recent builds of the docs for gforth 14:22:55 How did you obtain gforth f-a ? 14:23:08 debian buster 14:23:14 Which version are you on? 14:23:28 f@extensa:~$ gforth --version 14:23:28 gforth 0.7.3 14:23:51 I recommend downloading and building the latest version, a lot has been added since 14:24:33 https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ 14:24:50 Don't remove the current gforth you have, because I believe it's needed to build the newer version 15:30:29 --- quit: f-a (Read error: Connection reset by peer) 15:41:48 --- quit: inode (Ping timeout: 264 seconds) 15:43:50 --- join: dave0 joined #forth 16:18:48 --- quit: flashforth (Quit: Connection closed) 17:01:37 --- quit: dave0 (Quit: dave's not here) 18:33:20 --- nick: travisb_ -> tabemann 18:39:04 --- join: boru` joined #forth 18:39:07 --- quit: boru (Disconnected by services) 18:39:09 --- nick: boru` -> boru 20:21:29 --- quit: zolk3ri (Remote host closed the connection) 20:51:16 --- join: gravicappa joined #forth 20:59:47 --- quit: sts-q (Ping timeout: 240 seconds) 21:01:18 --- join: flashforth joined #forth 21:01:31 --- join: sts-q joined #forth 21:05:46 --- join: dave0 joined #forth 21:09:45 --- quit: jedb (Remote host closed the connection) 21:15:06 --- join: jedb joined #forth 22:13:00 --- quit: sts-q (Quit: ) 22:13:27 --- join: sts-q joined #forth 22:41:03 --- quit: flashforth (Quit: Connection closed) 23:34:41 --- join: hosewiejacke joined #forth 23:59:59 --- log: ended forth/21.02.16