2024-03-17 00:42:06 why not >r and 2>r then? 2024-03-17 00:42:35 skvery: it doesn't have to be. 8 bit machines usually have 16 bit forths 2024-03-17 15:26:51 Yeah, that is an issue and is particularly pesky if you're thinking about a hardware Forth in an FPGA. You've probably made the size choices precisely to optimize hardware resources, so there's no good way around it. 2024-03-17 15:26:58 I generally just avoid it. 2024-03-17 15:27:15 Forth "wants" those to have the same bit width. 2024-03-17 15:29:54 Is DTC Forth generally the most performant? 2024-03-17 15:30:03 What're the downsides to using DTC over ITC or STC? 2024-03-17 15:30:52 I've heard benchmarks say DTC is faster than STC, but I would guess optimised STC is fastest 2024-03-17 15:31:57 Unoptimised STC has worse cache coherancy, and usually slower data stack manipulation 2024-03-17 15:33:05 Yeah. I feel STC you need to work harder to get the same results. 2024-03-17 15:33:07 I tend to think STC is most often fastest, but I know there have been historical exceptions, at least a fairly long time ago. 2024-03-17 15:33:31 But yeah, I'm assuming the STC has been squeezed to be its best. 2024-03-17 15:33:33 There's not much downside to DTC over ITC 2024-03-17 15:33:38 DTC seems 1. simpler 2. faster. If STC is faster, is the speed increase marginal? 2024-03-17 15:33:48 A few simple optimisations make STC worth it, in my opinion 2024-03-17 15:33:54 I've always felt that ITC makes create/does> a little more elegant to implement. 2024-03-17 15:34:11 Some simple hinting about inlining for short words makes STC a LOT better 2024-03-17 15:34:14 Which is easy to do 2024-03-17 15:34:18 (Of course I'm asking this at all to form my own opinion of "the best forth" ;p) 2024-03-17 15:34:22 I mostly just prefer it because it's what I first became accustomed to, though. 2024-03-17 15:34:26 Emotional attachment. 2024-03-17 15:34:28 KipIngram: Does it though? I used to think same thing and in practice it didn't actually help. 2024-03-17 15:34:45 I think Starting Forth makes some mistakes in its description of ITC that make it seem better than it is 2024-03-17 15:34:53 Well, there's some reason I feel this way - it's from having written both kinds, not just something I read. 2024-03-17 15:35:00 Can't you do inlining with DTC too? 2024-03-17 15:35:09 It's been quite a while since i did DTC, though, so I'm fuzzy on the details. 2024-03-17 15:35:13 ITC is the 'retro' choice, it's the classic Forth model. It does definitely have sentimental attachment. 2024-03-17 15:35:16 I wouldn't think that's exclusive to STC 2024-03-17 15:35:29 You can do inlining with any model 2024-03-17 15:35:33 It works best in STC 2024-03-17 15:35:34 https://www.bradrodriguez.com/papers/moving1.htm#:~:text=A%20Forth%20%22thread%22%20is%20just,the%20CPU%20and%20the%20application. 2024-03-17 15:35:48 In STC you're just inlining machine code 2024-03-17 15:35:54 This Brad Rodriguez is an excellent writer 2024-03-17 15:36:12 (and apparently an excellent Forth thinker :)) 2024-03-17 15:36:45 > Subroutine threading may be faster than direct threading. You save time by not having an interpreter, but you lose time because every reference to a Forth word involves a push and pop of a return address. In a DTC Forth, only high-level words cause activity on the return stack. On the 6809 or Zilog Super8, DTC is faster than STC. 2024-03-17 15:36:51 I also feel like DTC doesn't let you keep your code in one compact space as well. There has to be a snip of code for every word, spread around. 2024-03-17 15:36:58 lf94: Some easier optimisations that are worth doing, in order of difficulty: inlining, constant folding, and peep-hole optimisation 2024-03-17 15:37:15 With ITC it can be one compact block, that you can expect to get all into your instruction cache. 2024-03-17 15:37:28 veltas: thanks 2024-03-17 15:37:39 I guess you could still get all those little places into your cache too, but it just feels a little disorganized to me. 2024-03-17 15:38:14 The instruction cache will get cluttered up with stuff that's not code with a DTC system. 2024-03-17 15:38:25 lf94: There is somewhere a good presentation I can't find on Mecrisp's optimisation techniques, that's worth finding. It's in German though! 2024-03-17 15:38:40 On a modern desktop machine, you'd want to keep your machine code, headers, threaded code and data separate, possibly separate cache lines 2024-03-17 15:39:07 Right - ITC facilitates that very nicely. 2024-03-17 15:39:09 I care mostly about Forth code that's performant from 8-bit cpus up to 64-bit 2024-03-17 15:39:24 Even if that means perf. loss on the higher bit CPUs 2024-03-17 15:39:39 You might want to look at Anton Ertl's stuff 2024-03-17 15:39:57 A have an ATTiny85 (AVR assembly) that I want to probably mess with Forth on. 2024-03-17 15:40:03 GeDaMo: will do 2024-03-17 15:40:30 On 8-bit you tend to focus on memory usage over raw CPU performance 2024-03-17 15:40:39 So DTC or tokenised forth 2024-03-17 15:40:42 https://www.complang.tuwien.ac.at/projects/forth.html and possibly https://www.complang.tuwien.ac.at/projects/interpreters.html 2024-03-17 15:40:49 DTC really seems to be the best balance 2024-03-17 15:40:53 Across all systems 2024-03-17 15:41:16 lf94: https://github.com/Veltas/zenv is ZX Spectrum 8-bit forth, can build DTC and tokenised 2024-03-17 15:41:25 Ah, here we go https://www.complang.tuwien.ac.at/forth/threaded-code.html 2024-03-17 15:41:25 As a build-time option 2024-03-17 15:41:39 Thanks GeDaMo 2024-03-17 15:41:55 GeDaMo do you have a list of prog. bookmarks or you just recall them? :p 2024-03-17 15:42:16 I do have a lot of bookmarks but I often remember keywords and search for them :P 2024-03-17 15:42:17 One day I need to aggregate all my bookmarks and save all the pages... 2024-03-17 15:42:45 veltas: f'n sick. 2024-03-17 15:42:51 Love it. 2024-03-17 15:45:40 I have a "popularity" theory: any PL that is exceptionally good (forth, lisp, etc), is not talked about by its users, because they are so content and solve their problems without effort, that they see no reason to even discuss it much 2024-03-17 15:46:55 veltas: does your z80 forth support num ops larger than 8 bits? 2024-03-17 15:47:32 I implemented a 64 bit arithmetic macro system for gameboy and it was neat but a bit of a pain 2024-03-17 15:47:41 I'm wondering if the same could be done within forth instead 2024-03-17 15:51:12 I'm tempted to porth zenv to gb in the future 2024-03-17 15:51:17 It's like 90% similar 2024-03-17 16:05:21 I'm surprised you didn't write the REPL part more in Forth 2024-03-17 16:18:17 I'm kind of surprised at the heavy use of DUP, SWAP, OVER, etc. I feel a lot of code would be easier to reason about if you directly referenced a position in the stack. 2024-03-17 16:18:30 Instead of mentally calculating where you are 2024-03-17 16:20:38 https://gist.github.com/lf94/e08a45f06829d9343ef72ccb365544b0 2024-03-17 16:23:26 Trying to mentally massage out a more natural way to read this 2024-03-17 16:23:53 I got this from https://forth-standard.org/standard/rationale#rat:core:REPEAT 2024-03-17 16:24:13 Is there a way to format this FACTORIAL word that makes the stack manips easier to mentally track? 2024-03-17 16:25:33 Maybe the initial decrement is what's throwing me off 2024-03-17 16:25:48 Lemme try rewriting it with 1- before the repeat 2024-03-17 16:31:28 At some point it would be nice to rewrite in a cross forth 2024-03-17 16:31:43 i.e. yes actually write forth instead of writing it all in assembler 2024-03-17 16:32:19 Nice nice; was just wondering if I had something wrong there / if the thought wasn't good 2024-03-17 16:32:46 So yes it's a 16-bit cell forth, which is natural for 8-bit machines 2024-03-17 16:32:59 Can do 32-bit with doubles 2024-03-17 16:33:58 My stack usage might not be ideal, it's not that easy to refine stuff in assembly, patches are welcome! 2024-03-17 16:34:11 yea yea 2024-03-17 16:41:44 https://gist.github.com/lf94/534c3b9545e9ed1c66821013496af172 aw yea, my own factorial :V 2024-03-17 16:42:22 Do you know about ?DO ... LOOP ? 2024-03-17 16:43:06 Not really lol 2024-03-17 16:43:14 What's a good way to benchmark this 2024-03-17 16:43:27 `time $(cat program.f | gforth)` ? 2024-03-17 16:43:49 Maybe time with a large number (even though it will overflow) 2024-03-17 16:44:44 Because gforth startup time probably isn't representative, and compilation takes time too 2024-03-17 16:44:54 benchmarking can be tricky to do right 2024-03-17 16:45:28 With a very large number you're reducing the error from that startup at least 2024-03-17 16:46:25 for one benchmark I ended up piping to dev null but it turned out that node leaked memory in a tight loop... 2024-03-17 16:46:46 veltas: Ill pick a number in the bajillions 2024-03-17 16:46:49 :p 2024-03-17 16:48:05 : FACTORIAL ( n-n) 0> IF 1 SWAP 1 ?DO I * LOOP ELSE 1 THEN ; 2024-03-17 16:48:10 Something like that might be faster 2024-03-17 16:48:14 Also might not 2024-03-17 16:48:33 Caveat untestor 2024-03-17 16:49:04 e.g. DUP needed at front 2024-03-17 16:49:11 DROP before 1 2024-03-17 16:49:21 : FACTORIAL ( n-n) DUP 0> IF 1 SWAP 1 ?DO I * LOOP ELSE DROP 1 THEN ; 2024-03-17 16:49:52 "stack overflow" huh (when using begin/while/repeat) 2024-03-17 16:50:51 guess my impl is broken 2024-03-17 16:51:49 Okay I've tested one now: 2024-03-17 16:51:52 : FACTORIAL DUP 0> IF 1 SWAP 1+ 1 ?DO I * LOOP ELSE DROP 1 THEN ; 2024-03-17 16:52:46 lf94: what's on the stack in the loop body? 2024-03-17 16:53:08 lf94: 1- decrements 2024-03-17 16:54:42 That loop isn't balanced 2024-03-17 16:55:38 You should have two values: the counter which is being decremented and the factorial so far 2024-03-17 16:56:04 yeah that's what I thought I had 2024-03-17 16:56:08 I would put the product on stack before the loop starts, it seems like you're putting it on the stack each iteration 2024-03-17 16:56:25 $ time gforth Code/tmp/factorial.f -e bye 2024-03-17 16:56:27 You haven't put the value so far on the stack before the loop 2024-03-17 16:56:27 <3> 3 4 3 <2> 12 3 <4> 12 2 3 2 <3> 12 6 2 <2> 12 6 2024-03-17 16:56:41 (4 factorial) 2024-03-17 16:56:41 For once I sniped GeDaMo :P 2024-03-17 16:56:45 :P 2024-03-17 16:57:01 I need 12 6 * 2024-03-17 16:57:27 Yes but you also need to keep track of which iteration you're on 2024-03-17 16:58:17 Also, you're testing if the value is greater than 2, doesn't that mean you won't multiply by 2? 2024-03-17 16:59:35 Not quite - and yes I was keeping track but it seems I lose the iter var along the way lol. 2024-03-17 17:00:10 It's funny, the way I thought about this problem is totally in line with what you're all saying 2024-03-17 17:00:19 stack var for iter, stack var for accumulator 2024-03-17 17:00:28 Goes to show Forth is actually readable :P 2024-03-17 17:00:34 But because my stack manip / tracking skills are zero / shittier, I'm having trouble 2024-03-17 17:00:38 People say it's write-only but that's not really true 2024-03-17 17:01:01 It's not easy but if you can even get forth code to run then usually it can be understood 2024-03-17 17:01:14 What I'm really bothered by internally is _needing any_ stack manip skills at all 2024-03-17 17:01:27 Surely there's an easy way to think about this 2024-03-17 17:01:45 Either through comments on the side, or formatting the code 2024-03-17 17:01:48 Well what vars do we want here, the counter and the product? 2024-03-17 17:01:56 Yea. 2024-03-17 17:02:03 I was starting to write the code in "L shapes" 2024-03-17 17:02:09 So keep either product or counter on the top, you choose, make sure they're ready before loop starts 2024-03-17 17:02:14 With my stack vars on the top 2024-03-17 17:02:21 and the operations on them beneath 2024-03-17 17:02:23 like 2024-03-17 17:02:24 You can put comments on each line if it helps 2024-03-17 17:02:42 It's a good way to start, before you get used to the stack 2024-03-17 17:03:56 https://gist.github.com/lf94/db4c18f492467d0bf3fc65102b5e9a53 2024-03-17 17:04:06 (I understand this doesnt work) 2024-03-17 17:04:15 surely there's a way to do some sort of code formatting like this 2024-03-17 17:05:17 I'm starting to see "swap" is a good synonym for "return" 2024-03-17 17:05:35 at least in a loop with some iter var 2024-03-17 17:07:53 It might help you to write stack comments like this https://pastebin.com/raw/DVfSbkYD 2024-03-17 17:08:38 Going through the earlier chapters of Starting Forth and doing the exercises is worth it, if you've not done that 2024-03-17 17:12:53 I haven't but I will now :) 2024-03-17 17:13:22 I've been more immediately interested in: can I express recursion, can I pass functions around, etc 2024-03-17 17:13:28 The answer to all is: yes 2024-03-17 17:15:19 As people have also said before, you don't have to use stack. It's worth trying it, and learning how. But you can use variables, even local variables if necessary. 2024-03-17 17:15:36 You can write C-style Forth as well, I did that a little at first 2024-03-17 17:16:04 It's good to know some of those creature comforts are available, if the need arises 2024-03-17 17:17:38 "Pascal in Forth" http://tangentstorm.github.io/winfield-pascal-83.html 2024-03-17 17:21:19 I would rather just learn how to properly use the stack :) 2024-03-17 17:21:41 Forth 2012 with locals: https://pastebin.com/raw/Qtcy7bQ1 2024-03-17 17:21:45 Just out of interest 2024-03-17 17:23:29 Question: do languages like C do similar stack manipulations or do they directly ref. positions in the stack? I've seen the latter when doing reverse engineering 2024-03-17 17:24:02 And recursively: : FACTORIAL DUP 2 < IF DROP 1 ELSE DUP 1- RECURSE * THEN ; 2024-03-17 17:24:13 Well, the latter when you're in a "deep function". Otherwise I see C copy stack vars around 2024-03-17 17:24:19 to regs and whatever 2024-03-17 17:24:24 lf94: Depends on the arch, but most archs will directly reference positions in stack 2024-03-17 17:24:27 if stack is even used 2024-03-17 17:24:38 rigth right 2024-03-17 17:24:49 Most of the time funcs of args N or less will use reg 2024-03-17 17:25:02 Yeah in C 2024-03-17 17:25:23 There's only a few forths with optimisation good enough to do this 2024-03-17 17:25:23 Surely there is some Forth which does similar on those archs? 2024-03-17 17:25:31 Treating regs as a set of stack vars 2024-03-17 17:25:45 gforth, mecrisp, swiftforth, probably some other professional ones 2024-03-17 17:25:51 esp. on x86 2024-03-17 17:25:58 It's not easy to treat regs as stack, in general 2024-03-17 17:26:13 But there's a ton of literature on this kind of optimisation, it's how many JITs work internally 2024-03-17 17:26:23 I feel like 6502 would be good for forth 2024-03-17 17:26:34 Yes I feel the same way 2024-03-17 17:26:36 with its "memory as regs" type of setup 2024-03-17 17:27:16 6502 cries for some kind of bytecode or interpreted language on top of its basic arch, in my opinion 2024-03-17 17:27:21 Like sweet 16 2024-03-17 17:27:22 yep 2024-03-17 17:27:46 It's nice we have x86 based forths with as much work in them as other langs 2024-03-17 17:27:57 So they can compete on efficiency 2024-03-17 17:28:44 There are some LLVM forths 2024-03-17 17:29:32 And most 'serious' forths have an assembler, so you can drop to assembly to squeeze extra performance 2024-03-17 17:30:43 If your aim with forth is to have a complete compiler/IDE that you can write and understand yourself, then providing an assembler and simple optimisations is the pragmatic approach, in my opinion 2024-03-17 17:31:17 Rather than trying to go for fuller optimisation techniques or integrating into massive compiler toolchains 2024-03-17 17:38:55 what's the difference between 0 = and 0=? Seems to be nothing when playing around in gforth repl 2024-03-17 17:39:26 I would rather 0 = and avoid "special words" like 0= 2024-03-17 17:40:29 some folks wanted them special words 2024-03-17 17:41:04 that's dumb but ok :V 2024-03-17 17:41:08 They translate to single instructions on some machines 2024-03-17 17:41:31 Surely you can optimize just looking for "0 =" instead of having to invent an entirely new word 2024-03-17 17:41:36 Yeah, and with decent optimisations you will see same code output for 0= and 0 = 2024-03-17 17:41:55 But that feature is advanced, 0= is easier to implement than optimisations 2024-03-17 17:42:58 Remember this started as a hacky personal project on mainframes in the 60's 2024-03-17 17:43:15 Be assured this is part of the charm ;) 2024-03-17 17:43:25 Wouldn't it be easier to write a little program to just combine 0 = 2024-03-17 17:43:30 on the string level 2024-03-17 17:43:41 Eh, yea 2024-03-17 17:43:55 forth originated on microcomputers where forth was the little program 2024-03-17 17:44:47 heh 2024-03-17 17:44:55 It's not incredibly hard but some of the optimisation techniques just weren't obvious to early forth implementors 2024-03-17 17:45:32 Chuck implemented a simepl type of optimization on colorforth that someone called pinhole optization 2024-03-17 17:45:34 I guess in your special forth impl you could easily reason that concatenating words is "the optimized word variant" 2024-03-17 17:45:45 dup0=if 2024-03-17 17:45:55 thrig: I think forth predates microprocessors 2024-03-17 17:46:12 It involved some words looking at previously compiled item; if it was a constant, an optimized machine code instruction would be used 2024-03-17 17:46:27 yeah, that was sloppy 2024-03-17 17:48:04 e.g. + would look back, see a constant, decompile it and instead use add TOS, constant 2024-03-17 17:49:19 what's the preferred way to loop by forth pros 2024-03-17 17:49:31 Depends on the situation 2024-03-17 17:49:36 and the forth 2024-03-17 17:49:47 what's the most simple loop construct that works in most cases 2024-03-17 17:50:12 Standard: begin while repeat / begin until / do loop / ?do loop 2024-03-17 17:50:18 There's not a lot of loop types 2024-03-17 17:50:29 Although you can construct your own if you like 2024-03-17 17:50:40 and the pros use: begin while while while repeat then then 2024-03-17 17:51:04 https://forth-standard.org/standard/rationale#paragraph.A.3.2.3.2 2024-03-17 17:53:11 IF THEN + BEGIN UNTIL seems to be what I'm looking for 2024-03-17 17:54:21 Making your own loop construct makes sense if e.g. you want to loop over all characters in a string, something like that 2024-03-17 17:54:39 Although I tend to write words that will produce a range of addresses for ?DO..LOOP 2024-03-17 18:00:43 How would you indefinitely push an item on the stack 2024-03-17 18:00:54 I'm going even simpler and trying to implement a "sum" 2024-03-17 18:02:48 begin again 2024-03-17 18:02:52 Is infinite loop 2024-03-17 18:03:07 not sure what you're after 2024-03-17 18:03:53 Give a stack 5 4 3 2 1 N, how do I say, push N to the very back? 2024-03-17 18:04:04 It's just a fun question and not used for the sum exercise 2024-03-17 18:04:11 ROLL 2024-03-17 18:04:33 could also write a word to do it using return stack 2024-03-17 18:07:01 I feel like that'd be a good exercise 2024-03-17 18:07:17 I think something like that is an exercise in starting forth 2024-03-17 18:07:26 I'll look for the chapter 2024-03-17 18:09:33 Chapter 2 has some early stack exercises at end 2024-03-17 18:09:49 I'm looking at the first edition PDF that's on forth.com 2024-03-17 18:13:31 Ah ok 2024-03-17 18:13:40 aside: I think BEGIN AGAIN is actually better 2024-03-17 18:14:06 BEGIN ... IF AGAIN THEN ... 2024-03-17 18:14:39 What you're trying to do there is what begin..while..repeat does 2024-03-17 18:14:45 Yeah I know :) 2024-03-17 18:15:15 On many forths you can do: BEGIN ... IF [ SWAP ] AGAIN THEN 2024-03-17 18:15:25 That's how WHILE is implemented on most forths 2024-03-17 18:16:57 BEGIN pushes the start address of the loop, AGAIN consumes it. Likewise IF pushes the address of the place where the branch destination needs to be written and THEN writes the current position to that address, popping it 2024-03-17 18:18:13 lf94: Mentioned earlier, this is the video with info about mecrisp's optimisations, in case you want to bookmark https://www.youtube.com/watch?v=a8Dg08DkILo 2024-03-17 18:23:05 Hm, chapter 2s content on stack manip doesn't make it clear to me how I can move N to the very end of 5 4 3 2 1 2024-03-17 18:23:16 (or any arbitrarily long list of stack elements) 2024-03-17 18:23:32 These stack manip functions can only reach so far 2024-03-17 18:24:07 Say I have 5 N 4 3 2 1 - how do I make the final move for 5 and N? 2024-03-17 18:24:24 Chapter 5 introduces return stack 2024-03-17 18:24:32 Which would probably be necessary for this 2024-03-17 18:26:32 >R and R> etc 2024-03-17 18:27:17 Yea, this makes much more sense now 2024-03-17 18:27:24 What does the return stack look like at the asm level? 2024-03-17 18:27:38 Still using the regular SP ? 2024-03-17 18:30:32 Depends on the registers selected by your Forth 2024-03-17 18:30:44 With STC the return stack would be the main stack pointer 2024-03-17 18:32:31 And what about the parameter stack? Same deal? 2024-03-17 18:32:39 A bit mind bending to think they use the same SP 2024-03-17 18:32:52 No STC would use another reg for parameter stack 2024-03-17 18:34:55 How are the two stacks laid out in memory? One grows up and one grows down? 2024-03-17 18:35:09 Usually all stacks grow down, but it's up to you 2024-03-17 18:35:24 you dont really need a huge parameter stack 2024-03-17 18:35:43 I'm thinking about arbitrarily large stacks 2024-03-17 18:35:45 The return stack sometimes is placed at end of dictionary area, so that the dictionary can overlap return stack area 2024-03-17 18:35:49 That eventually take up all memory 2024-03-17 18:35:58 one growing down and the other growing up would make sense if you wanted the rest of memory to be devoted to it but you need most of your memory for the dictionary 2024-03-17 18:36:31 so there must be a set size on the parameter stack? is it usually adjustable? 2024-03-17 18:36:56 Not usually no, and it doesn't need to be that deep 2024-03-17 18:37:07 Making memory sizes dynamically adjustable has a cost 2024-03-17 18:37:17 I meant before running the forth system 2024-03-17 18:37:35 How is the parameter stack not a set size? 2024-03-17 18:37:43 some forths let you do this. it doesnt make sense on a PC but could matter on a microcontroller 2024-03-17 18:37:46 I've seen multiple forths align stacks to 256 byte regions to allow some optimisations with pushing/popping 2024-03-17 18:38:42 zenv for example restricts the stacks to 256 byte areas so I can do push/pop with two 8-bit decrements/increments 2024-03-17 18:39:04 I think KipIngram did something like this for his forth (?) 2024-03-17 18:39:10 Or attempted to 2024-03-17 18:39:47 I think I misunderstood what you said lf94, yes many forths allow configuring a specific size for parameter stack 2024-03-17 18:40:45 ah ok, yea 2024-03-17 18:41:15 I'm thinking like what if I had 4gb of numbers I want to sum 2024-03-17 18:41:27 I guess I do some I/O that reads 1 number at a time 2024-03-17 18:41:42 Conventionally that can go in dictionary 2024-03-17 18:41:43 But what if I stuff 4gb of numbers into a forth program 2024-03-17 18:41:45 :V 2024-03-17 18:41:58 You can allocate/deallocate memory to/from end of dictionary trivially in forth 2024-03-17 18:42:03 with ALLOT 2024-03-17 18:42:21 I havent touched dictionary yet 2024-03-17 18:42:27 and words like C, , HERE etc 2024-03-17 18:42:38 ACTION reads 2024-03-17 18:43:08 MARKER 2024-03-17 18:43:36 FORGET ya ever saw me :P 2024-03-17 18:45:55 allocating dictionary space for that works like a stack so you cant allocate 2gb for task A then 2gb for task B then free the memory for task A since the memory for task B would have to be freed first 2024-03-17 18:46:52 And this is the crux of the point I made earlier about how allowing dynamic sizing is inherently costly. The dictionary's cost is the fact the allocations are a stack and are 'ordered' 2024-03-17 18:47:03 The advantage of dictionary is purely simplicity 2024-03-17 18:49:17 "dictionary is usually a linked list" 2024-03-17 18:49:29 on smaller systems this is probably a regular array right 2024-03-17 18:50:02 The dictionary area is just memory, the 'dictionary' proper is usually a linked list of word definitions 2024-03-17 18:50:09 yea that's what i mena 2024-03-17 18:50:27 What're the usual words for forth file i/o? 2024-03-17 18:50:39 But the memory allocated with ALLOT is just flat memory, could be used as an array or whatever 2024-03-17 18:50:42 (Also I'd ask all these questions to ChatGPT but it's much nicer talking with real people :) 2024-03-17 18:50:55 I'm not sure how much ChatGPT could help with this 2024-03-17 18:51:07 It's pretty much answering everything 2024-03-17 18:51:17 The standard disk I/O is block words, as described in starting forth 2024-03-17 18:51:25 There's also actual file I/O words in the standard 2024-03-17 18:51:46 https://forth-standard.org/standard/block https://forth-standard.org/standard/file 2024-03-17 18:52:20 The 'block' access in embedded devices and where Forth is the OS are often literally just disk blocks 2024-03-17 18:52:29 i.e. block 0 is the MBR! 2024-03-17 18:54:56 But in gforth the blocks just go in a file in the current directory 2024-03-17 18:55:08 called blocks.dat or something boring like that 2024-03-17 18:57:48 hm 2024-03-17 18:58:09 open-file read-file write-file is quite a nice interface 2024-03-17 18:58:45 On systems that abstract files I think I'd prefer this 2024-03-17 18:59:08 But on systems like microcontrollers, what are my options to arbitrarily access device ports? 2024-03-17 18:59:16 Special words? 2024-03-17 18:59:22 Implemented on that system's forth? 2024-03-17 18:59:51 Or are there forth words that say "you can poke or peek X memory address" 2024-03-17 19:00:49 This is what ChatGPT gave me for asking how I can write ROLL: https://pastebin.com/raw/bEseFpFu 2024-03-17 19:01:39 That code is 100% nonsense, and all the comments I've read are wrong 2024-03-17 19:01:50 I was gonig to say 2024-03-17 19:01:55 Looks completely wrong lmao 2024-03-17 19:02:15 I was more commenting on ChatGPT being able to answer questions like "how do you do file i/o in forth" 2024-03-17 19:02:52 What's interesting about ChatGPT is anything where it actually has to think, you end up doing all the thinking for it 2024-03-17 19:03:00 yeah yeah lol 2024-03-17 19:03:05 I use it as a better Google 2024-03-17 19:03:25 They need to really include links and stuff though in output 2024-03-17 19:03:38 chatgpt is basically automated plagiarism 2024-03-17 19:03:43 I just asked it about file I/O and again it generated a load of nonsense 2024-03-17 19:03:59 I'm not that surprised, ChatGPT is better at interpolating well-trodden areas of conversation 2024-03-17 19:04:05 Forth doesn't have as much data to crawl 2024-03-17 19:04:19 It got some of the word names correct 2024-03-17 19:04:21 https://chat.openai.com/share/e/db8760e2-aec2-487b-9a7c-f985d9a8b295 seems ok 2024-03-17 19:04:49 that's how I typically use it, asking mundane questions that usually involve crawling already existing docs 2024-03-17 19:04:56 I can't open that share 2024-03-17 19:05:04 What prompt do you recommend? 2024-03-17 19:05:22 > tell me about the forth programming language's dictionary and how to use 2024-03-17 19:05:26 is the first prompt on that link 2024-03-17 19:05:29 and the second is ... 2024-03-17 19:05:39 > How do you do File I/O in Forth? What words do I need? 2024-03-17 19:06:20 I think ChatGPT is great *if* you use it knowing how it *actually* works and that you must be very careful 2024-03-17 19:06:51 For real it's just a better Google, and then I revert to Google when I need more concrete human written stuff to read into 2024-03-17 19:07:00 What's interesting about ChatGPT is it seems to respond with a sort of middle-tier accuracy on everything, it's like every response is by a half-understanding reddit user 2024-03-17 19:07:15 When it's not just total nonsense, that is 2024-03-17 19:07:18 yea 2024-03-17 19:07:23 that doesn't sound very interesting at all tbh 2024-03-17 19:07:28 it sounds useless 2024-03-17 19:07:45 I've actually had a hard time explaining to my brother that bash code it wrote was 1. shit and 2. pretty much wrong 2024-03-17 19:07:53 "but yo it looks completely right" 2024-03-17 19:08:04 that's easy. "so run it" 2024-03-17 19:08:05 I told him: the LLM is designed to output content that makes the reader happy 2024-03-17 19:08:26 Is it useless though? Many of these reddit users get by in jobs and have salaries. I think it's impressive they've got a machine that can replace lots of average people. 2024-03-17 19:08:29 It doesn't know anything and is just doing its best to pattern match some text that makes you happy 2024-03-17 19:08:44 I do wonder what the gap to bridge between half-intelligent and intelligent is 2024-03-17 19:09:21 zelgomer: the thing is most of the code questions he asks from it does produce runnable code that barely works for an extremely narrow set of input data (usually the input data used as an example he gives)... 2024-03-17 19:09:35 then yes, it usually breaks when he actually goes to use it for the original thing he needed it for 2024-03-17 19:09:51 veltas: yes. i work with those people. nobody will admit it, but we were more productive before we hired them 2024-03-17 19:09:52 he's seen this now about 4-5 times and it's finally clicked 2024-03-17 19:10:02 but before that? it's hard to explain to people. they just dont believe you 2024-03-17 19:10:19 corporate software is basically a jobs program 2024-03-17 19:11:59 anyway: forth on microcontrollers. device ports. how? 2024-03-17 19:12:19 custom words on ? 2024-03-17 19:12:40 complete sentences 2024-03-17 19:12:59 agree 2024-03-17 19:13:44 I was thinking you could use ! and @ directly on memory addresses 2024-03-17 19:13:48 If it's memory mapped, yes 2024-03-17 19:14:16 mecrisp is good for microcontrollers 2024-03-17 19:14:16 It's a microcontroller, why do you need a memory map :p 2024-03-17 19:14:31 Lots of em are memory-map-IO 2024-03-17 19:14:38 veltas: I figured that when I saw the video's title slide hahaha 2024-03-17 19:15:01 ChatGPT I just asked it to write an episode of Monk, and it wrote something about an abbey and actual monks. 2024-03-17 19:15:27 I corrected it and told it to write about the detective show and it started writing some really bad fan-fic-tier stuff 2024-03-17 19:15:38 ah mmap io, yes - sorry, i was thinking mmap in some other way, like file -> memory but yeah mmap of different memory modules and device ports is common, my bad 2024-03-17 19:15:44 Was there a monk called Cadfael? :P 2024-03-17 19:15:54 Although probably good enough for the real show, I still love it 2024-03-17 19:16:13 OK so Forth's got me on the microcontroller side and the high level filesystem side 2024-03-17 19:16:19 excellent 2024-03-17 19:17:24 Forth is incredibly capable but it is just very tedious in many respects. It CAN do anything but it's been public for 50+ years and doesn't have widespread adoption for a reason 2024-03-17 19:17:33 It's always had a sweetspot for embedded or small computers 2024-03-17 19:17:58 It was the first high-level language in space for a reason, and popular among astronomers 2024-03-17 19:18:48 Isn't the reason because we gotta track the stack? I think that's literally the only reason 2024-03-17 19:19:38 Why hasn't the forth community joined together, combine its 100 smart brains, and solve the stack reasoning problem? 2024-03-17 19:19:47 That's a big deal, although it's not actually necessary to use the stack for anything other than evaluation order 2024-03-17 19:19:55 if you use locals etc 2024-03-17 19:20:23 It's also not a typed language, there's no type system or type checking 2024-03-17 19:20:39 *are* locals the solution to the stack reasoning problem? 2024-03-17 19:20:57 If you want a blunt instrument to solve the problem then yes 2024-03-17 19:21:00 I don't think a type system makes sense at this level 2024-03-17 19:21:14 The nuanced answer is to refit the problem to use less vars at once, but in general that's not always possible 2024-03-17 19:21:17 Or stack comments 2024-03-17 19:21:39 You could put type information in higher level words sure 2024-03-17 19:21:52 but once you reach primitives it doesn't make sense 2024-03-17 19:22:05 I think for sure a type system could be "bolted on" 2024-03-17 19:22:08 The mindset of forth is to *never* write the 'general' solution though, apply "you aren't gonna need it" to the extreme 2024-03-17 19:22:22 Yes, I think this is a good mindset. 2024-03-17 19:22:23 Yes type systems are plausible, I've not seen a good one 2024-03-17 19:22:45 There's been functional concatenative languages, I assume they come with better type situation 2024-03-17 19:23:02 I'm more interested in a forth type system that is as simple as forth itself :) 2024-03-17 19:23:37 I think the functional stuff probably is quite simple and sweet, as soon as you want things like "type systems" and "simple" you probably want a functional lang 2024-03-17 19:23:43 That's not the forth route 2024-03-17 19:23:45