2024-06-01 00:15:05 dzho: thanks. yeah, i'm aware of the methods of how to share and the steps i'd have to take to do it, the problem is more on my side. that i haven't decided on how i would want to go about it. like i said, i think i've pretty much talked myself into preferring to write a blog post or article. in other words, the decision ahead of he isn't so much "how do i make this code publicly accessible," it's 2024-06-01 00:15:11 "specifically what do i want to publish, in what format, and what do i want to say about it?" ideally the answers to those questions would be something that can represent a benefit to me. 2024-06-01 00:17:09 if i were to go through with it, the current most likely candidate would be an i2p eepsite. i2p needs more content, anyway. but then you assholes can't reach it unless you are into i2p, which you shoupd be. 2024-06-01 00:51:27 I finished the My4th boards :) 2024-06-01 00:51:36 I will be taking a video I think tomorrow 2024-06-01 01:04:22 taking it where? 2024-06-01 02:39:03 just don't take it late for dinner 2024-06-01 08:10:23 Where can I learn more about DOES> in detail, how it is implemented and how it works? 2024-06-01 08:16:10 Think of it as a combination of a VARIABLE and a : word. You define the : word when you write the defining word - it's the stuff that comes after DOES>. The instructions for how to allocate the RAM for the VARIABLE part come between CREATE and DOES>, but the RAM isn't actually allocated until you USE that word to define a new word, say foo. 2024-06-01 08:16:30 When you run foo, the address of the variable part's RAM is put on the stack, and the DOES> code is run. 2024-06-01 08:17:33 The final word foo has to have access somehow to both the DOES> code and the RAM allocated for foo. So the definition of such words has an extra field in it somewhere. Details can vary. 2024-06-01 08:18:05 It can take a little while to get your head around it. 2024-06-01 08:20:27 In a traditional Forth system a VARIABLE will have a pointer to a bit of machine code we call "dovar," and a pointer to the RAM allocated for that variable. So two pointers. A : defined word will have a pointer to machine code we call docol, and a second pointer to the list of addresses defining the word. So two pointers again. One way of implementing CREATE / DOES> winds up giving the final words three 2024-06-01 08:20:29 pointers - a pointer to machine code I call dodoes, a pointer to the code defined after DOES>, and a pointer to the RAM allocated for that word. 2024-06-01 08:20:32 That's just one way to do it, though. 2024-06-01 08:21:28 Plain variables just stick the address of the RAM on the stack when they execute. DOES> words stick that address on the stack AND THEN RUN CODE ON IT. 2024-06-01 08:21:46 So they're like variables with an action attached. 2024-06-01 08:31:52 smlckz: https://www.bradrodriguez.com/papers/moving3.htm 2024-06-01 08:32:13 From 3rd heading 2024-06-01 09:18:09 In zenv all CREATE words start with CALL create_code, as it's DTC or tokenised direct threaded depending on build options 2024-06-01 09:20:12 If (DOES) executes it replaces the last definition's called address with R> i.e. code following (DOES) which also causes exit from the colon word (DOES) was in 2024-06-01 09:21:17 by popping return stack before running NEXT 2024-06-01 09:22:37 So the address of the data is available to the DOES>-compiled code following because it's at R> 2024-06-01 09:24:34 Brad Rodriguez explained you always have some known 'register' that the xt of the word being executed ends up in before the code is executed, and so that register is where your does>-compiled code can find the associated data 2024-06-01 09:25:01 But in zenv that 'register' is the return stack 2024-06-01 09:25:56 There's no overhead for CREATE words in classic forths, the extra overhead appears when you separate code from data 2024-06-01 09:26:16 Because you can't execute a word and know where the data is without doing extra work, or adding extra info somewhere 2024-06-01 09:29:47 Separating code from data is necessary on modern forths because modern CPUs need essentially harvard architecture for optimal caching 2024-06-01 09:30:45 So that's either enforced (PPC/ARM?) or carries a huge performance benefit (x86) to keeping the two separate 2024-06-01 09:31:08 I say 'enforced', you can do it you just need to provide the right synchronisation for it to take effect, so with normal read/write it won't work 2024-06-01 09:31:38 x86 just detects such changes and does the synchronisation work automatically because it's simulating a dated CPU 2024-06-01 09:37:44 'when you separate code from data'; or code *fields* from data, as in ITC forths 2024-06-01 10:41:04 Looks like fig-forth has MYSELF to do recursive calls 2024-06-01 10:42:46 I now wish to unsee or unread this statement: “The Code Field is the single "method" for this "class" of words, and the Parameter Field contains the "instance variables" for this particular word.” Due to the [[equivalence of objects and closures][https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent]], isn't this a freaking closure as well?? 2024-06-01 10:48:33 Not sure honestly 2024-06-01 11:18:05 I would say no 2024-06-01 11:18:08 It's pushing it 2024-06-01 11:18:17 I don't find these functional discussions too productive 2024-06-01 11:21:52 A forth word usually has code and data attached, you can see that as similar to an object 2024-06-01 11:25:13 it isn't closure just like that, but this setup provides a very low-level way to build closures.. 2024-06-01 12:06:42 GeDaMo: Yeah but an object isn't a 'closure', I don't really care what that linked page tries to say 2024-06-01 12:07:00 One may also see on the page that there's a lot of discussion about whether the question is true 2024-06-01 12:07:04 Mostly people are saying 'no' 2024-06-01 12:07:25 I don't care what the majority thinks, I'll just say 'no' on the basis it's not true in any helpful way 2024-06-01 12:09:23 smlckz: Do you know about DOES> words? 2024-06-01 12:11:04 That is Forth's classic high-level way to associate data and code, it's still not a 'closure', or an 'object', but people compare it to both 2024-06-01 15:21:57 If you don't want any overhead then you'd need a copy of the code with every instance of the words defined with your defining word. You can replace that copy with just a pointer to the one copy if you want to. 2024-06-01 15:22:16 I guess I'd call that code copy overhead too. 2024-06-01 15:23:37 One way or another those words have to know both what data address to push and what code to run. 2024-06-01 16:19:55 It gets sent the same way as it's sent to (CREATE) 2024-06-01 16:27:59 Sure it's overhead but it's not per-CREATE, it's per-definer 2024-06-01 16:42:51 Every word you define with a defining word has to be able to get at those two things - that amount of information must be associated with them somehow. 2024-06-01 16:43:34 And that's more information than either a VARIABLE or a : word have themselves - a VARIABLE doesn't have to be able to find a definition, and a definition doesn't have to find any data. 2024-06-01 16:45:01 In the old traditional systems a VARIABLE would have its pointer to dovar, and the data would immediately follow that pointer. A : word would have its pointer to docol, and the definition would immediately follow that pointer. A CREATE / DOES> defined word somehow has to do both of those things, so it will require an extra pointer or some form of extra information. 2024-06-01 16:45:37 In more modern systems that "immediately follows" has often gotten replaced by another pointer. 2024-06-01 16:48:51 Are you thinking of a subroutine threaded system? 2024-06-01 16:51:22 You might be able to cut the pointer count down by one in subroutine threading. 2024-06-01 16:51:55 And perhaps merge the address push into the DOES> code, even though you don't explicitly type it. 2024-06-01 16:53:09 But that would still differ from a standard : def in that it would somehow need to know what the address of the data was so that it could push it. 2024-06-01 16:57:03 Primitives take one address less - you just need the pointer to your code and your done. And in a code-threaded system I guess a : definition looks like a primitive - you just need the pointer to that code. And if data is associated, then you need to know where that is. So I guess in that architecture a DOES> word could look like a variable. Just pointing to more involved code. 2024-06-01 17:24:48 veltas> Looks like fig-forth has MYSELF to do recursive calls -- where did you see this? 2024-06-01 19:22:00 zelgomer: In the PDP-11 DAT file 2024-06-01 21:08:35 i think i don't like forth's memory model 2024-06-01 21:11:26 veltas: interesting. i was looking at thr pdp-11 user guide and didn't see any reference to it 2024-06-01 21:23:54 i might change my "self" to "myself" just for the similarity 2024-06-01 21:26:28 zelgomer: http://www.forth.org/library/eforth_SOC/eforth_SOC_source/figforth/PDP11DAT.ZIP 2024-06-01 21:26:40 yeah i found it 2024-06-01 21:26:58 also interesting that they find cfa from the pfa 2024-06-01 21:27:07 xxd -c64 11FORTH.DAT | sed 's/.\{171\}//' | sed 's/[[:space:]]\+$//' > 11forth.txt 2024-06-01 21:27:27 it makes more sense to me if you treat the pfa as payload to the cfa rather than the other way around 2024-06-01 21:27:48 veltas: fold -w 64 11FORTH.DAT :) 2024-06-01 21:28:01 I know that's a dumb way to do it I just am showing my hacky conversion in case it was helpful 2024-06-01 21:28:38 That's a good command for reference 2024-06-01 21:28:43 i went through the same thing when i started looking at old forth sources, too. that's actually how i eventually discovered the fold command. 2024-06-01 21:29:13 As I said earlier I just let it all hang out lol 2024-06-01 21:37:53 Yeah will use that 2024-06-01 21:39:03 if you use vim, i usually even do it just in the buffer. vim 11FORTH.DAT and then :%!fold -w 64 2024-06-01 21:39:11 just remember not to save it 2024-06-01 21:39:14 Nice 2024-06-01 23:17:57 fold 11FORTH.DAT -w 64 | sed 's/\s*$//' > 11forth.txt 2024-06-01 23:18:02 Remove trailing spaces 2024-06-01 23:18:08 But easy to do in vim too I guess 2024-06-01 23:18:44 That's a useful command though 2024-06-01 23:22:44 thanks, i'll take full credit for it