13:46 <nitrix> 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?

13:46 <nitrix> I haven't managed to find reliable information, especially with caching. If anyone knows, thanks in advance x]

13:46 <dave0> oh shit it's nitrix !

13:46 <dave0> hi nitrix

13:47 <nitrix> dave0, I'm joining the dark side, I think.

13:47 <dave0> i don't know sorry, i'm a newbie

13:48 <veltas> nitrix: Is the hypothesis something like if the code is smaller because of the threading model it might have less cache penalty?

13:50 <nitrix> 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.

13:52 <veltas> I don't know but I'm assuming it is generally slower as basically all mature x86 forths generate optimised machine code

13:54 <nitrix> Does the "optimised machine code" does register allocation?

13:57 <veltas> 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

13:57 <patrickg> 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)

13:58 <veltas> 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

14:12 <nihilazo> hi, I'm a complete newbie, I'm confused by the problem in starting forth chapter 2 to implement 3DUP

14:12 <nihilazo> 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

14:13 <Zarutian_HTC> nihilazo: know of the R> and >R words?

14:14 <nihilazo> they haven't come up yet in the book

14:16 <Zarutian_HTC> have you read chapter 2 to the end? /me trying to recall if >R and R> are introduced there or not

14:18 <nihilazo> they don't seem to be there, I'm reading the web version

14:24 <inode> nihilazo: what about PICK?

14:25 <nihilazo> nope

14:25 <nihilazo> I have swap, dup, over, rot, drop, 2swap, 2dup, 2over, and 2drop

14:25 <nihilazo> I assume I am intented to use 2over etc to implement 3dup

14:27 <inode> i can think of one combination that will do it, do you want it?

14:29 <nihilazo> sure

14:29 <inode> DUP 2OVER ROT

14:38 <Zarutian_HTC> 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

14:39 <inode> Zarutian_HTC: thanks for the tip, but i'll worry about that when you send me an RTX2010 to play with ;)

14:41 <Zarutian_HTC> eh, it also makes it faster on JITing Forth runtimes as there is no dynamic index into data dependency

14:43 <inode> 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 :)

14:43 <nihilazo> when it says 2dup is (d -- d d), I guess that is a pair of numbers on the stack rather than a single one

14:44 <nihilazo> 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

14:52 <MrMobius> 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

16:39 <proteusguy> 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

16:39 <proteusguy> 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.

19:34 <f-a> I am writing a simple «test» word, to test words

19:34 <f-a> as now it simply is : test ' execute = ;

19:35 <f-a> is there a way to print the name of the word I am testing?

19:35 <f-a> ideally I would like

19:35 <f-a> 9 3 square-me "square-me works!"

19:35 <f-a> 10 3 square-me "square-me does *not* work!"

19:41 <Zarutian_HTC> f-a: look into how the ' word works

19:41 <Zarutian_HTC> with see '

19:50 <lispmacs[work]> f-a: i think the word `word' grabs the next word from the input stream and returns it to you as a string

19:51 <f-a> super

19:51 <lispmacs[work]> f-a: double checking that...

19:55 <lispmacs[work]> f-a: I think `parse-name' is what I was looking for, a.k.a., `parse-word'

19:55 <lispmacs[work]> at least, those are the ones in gforth

19:56 <f-a> indeed indeed, I should have checked that with se- yes me too using gforth

19:57 <lispmacs[work]> 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

21:56 <veltas> f-a: How do you know if a word works or not?

21:57 <veltas> Oh right I see now you give a desired result then the input

21:58 <f-a> oh yes I should have described the problem more accurately

21:58 <f-a> yeah I would like a "Dear Sir/Madam, your word XYZ fails the test"

21:58 <veltas> No it's my fault I'm trying to do two things at once

22:10 <veltas> f-a: : test bl word dup >r find drop execute r> count type = if ." works!" else ." does *not* work!" then ;

22:10 <veltas> 9 3 test squared \ squared works!

22:10 <veltas> 10 3 test squared \ squared does *not* work!

22:13 <f-a> super useful, I am going to `see` all of them words

22:13 <veltas> 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

22:13 <f-a> thanks

22:13 <veltas> e.g. T{ 1 0 AND -> 0 }T

22:13 <f-a> ohhh

22:13 <veltas> Checks that after "1 0 AND" you get 0 on stack and nothing else for example

22:15 <f-a> bl is… ?

22:15 <veltas> ' '

22:15 <f-a> see bl

22:15 <f-a> 32 Constant bl

22:15 <f-a> `see` is sometimes a bit uninformative without comments

22:15 <f-a> thanks

22:16 <veltas> Check out forth-standard.org

22:18 <veltas> f-a: Which forth are you using?

22:20 <veltas> Funny how the BL word has so much activity on it

22:20 <f-a> gforth, veltas

22:22 <veltas> f-a: https://gforth.org/ https://gforth.org/manual/Word-Index.html#Word-Index

22:22 <veltas> That website has I believe recent builds of the docs for gforth

22:22 <veltas> How did you obtain gforth f-a ?

22:22 <f-a> debian buster

22:22 <veltas> Which version are you on?

22:23 <f-a> f@extensa:~$ gforth --version

22:23 <f-a> gforth 0.7.3

22:23 <veltas> I recommend downloading and building the latest version, a lot has been added since

22:24 <veltas> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/

22:24 <veltas> Don't remove the current gforth you have, because I believe it's needed to build the newer version