2024-04-21 00:45:28 endianness is really messing with my sha256 impl 2024-04-21 00:45:34 with this refactor 2024-04-21 01:44:50 this is maybe the half-week of being propped up by caffeine instead of sleep, but 2024-04-21 01:45:10 I've been writing forth for years and still get ROT and -ROT flipped around regularly 2024-04-21 01:45:19 i'm considering renaming them to DIG and BURY... 2024-04-21 02:34:43 rot is left because it makes more sense to go that way 2024-04-21 02:35:10 ive noticed rot was probably determined purely based on experience 2024-04-21 02:50:08 i think of rot as bringing the 3rd item to the top 2024-04-21 02:50:39 i can't explain why that helps me remember, but it is the more common use case in my experience 2024-04-21 03:00:17 I find rot pairs with ! nicely in so many scenarios 2024-04-21 03:00:37 because of the pairing 2024-04-21 03:36:50 regarding the news around the Z80, is it only the bare cpu that is being discontinued? 2024-04-21 04:19:55 there are many atmel and pic cpus 2024-04-21 07:01:34 Welp I'm pretty convinced if you can keep your data on the stack, do it 2024-04-21 07:01:54 This alternative sha256 with dictionary space for the operations is actually a pain in the ass 2024-04-21 07:03:17 I guess I should use the dictionary as a 3rd stack 2024-04-21 07:03:23 after all definitions 2024-04-21 07:13:20 Im done with this variable based one. It just sucks way too much 2024-04-21 07:16:41 stakbgood 2024-04-21 07:17:31 your vocabulary in theory should be concise, specific, and work for a job. 2024-04-21 07:18:13 your stack use, or desire will show your intent. 2024-04-21 07:18:35 if you are trying to do framework programming, go to a higher level. 2024-04-21 07:39:51 Eh even the dictionary as a 3rd stack sucks 2024-04-21 07:40:09 You have to 1 allot and 1- allot, all over the place 2024-04-21 07:40:19 and ! and @ 2024-04-21 07:40:40 vs just using the parameter stack. 2024-04-21 07:43:39 if the dict sucks, don't use it 2024-04-21 07:43:57 make your own, optimize prime 2024-04-21 08:17:19 Ok guys, it's done. I'm looking for feedback on how I could improve. https://gist.github.com/lf94/7197ccf7b4c1cceef15e816251b23781 2024-04-21 08:18:12 This new variant assumes the smallest cell on most systems (16-bits), and uses variables where it makes the code simpler, and the stack when it's simpler the other way 2024-04-21 08:18:29 Night! 2024-04-21 08:25:50 lf94: does r>.. actually work? What happens to the return address? 2024-04-21 16:53:32 GeDaMo: what do you mean it does it actually work? 2024-04-21 16:53:35 yes it works 2024-04-21 16:53:48 Guys, I need feedback :2 2024-04-21 16:53:55 lf94: Gimme a link 2024-04-21 16:53:58 I'm gonna go paint my living room ceiling and when I'm back I hope there's feedback! 2024-04-21 16:54:03 https://gist.github.com/lf94/7197ccf7b4c1cceef15e816251b23781 2024-04-21 16:54:14 > This new variant assumes the smallest cell on most systems (16-bits), and uses variables where it makes the code simpler, and the stack when it's simpler the other way 2024-04-21 16:54:25 lf94: Aye, I'll wait until you get back :) 2024-04-21 17:32:34 user51: just add comments to the file :) 2024-04-21 17:36:35 lf94: you pull the return address off of the return stack but don't put it back 2024-04-21 17:37:05 what line 2024-04-21 17:37:35 r>.. 2024-04-21 17:38:32 ah, I actually don't use this definition at all 2024-04-21 17:38:41 it was to match >r.. 2024-04-21 17:38:41 Yes, I noticed that :P 2024-04-21 17:38:46 my bad 2024-04-21 17:39:00 removed; updated gist 2024-04-21 17:40:18 are you able to fork the gist to add comments? 2024-04-21 19:13:31 GeDaMo: no comments? :) 2024-04-21 19:37:01 Sorry, I didn't try forking, I don't use github 2024-04-21 20:08:23 fork you, man 2024-04-21 20:15:07 github at least hasn't (yet) broken git clone 2024-04-21 21:24:50 GeDaMo: i meant just in general here :p 2024-04-21 21:26:13 lf94: : message.ptr message cell+ ; 2024-04-21 21:26:45 i saved you 3 cells there 2024-04-21 22:00:01 so if one were implementing a cross-compiling forth... how would you expect for does> to work? 2024-04-21 22:00:59 i'm using { } words to switch between host compiler vocabulary and target vocabulary. so for example, : this is a host word ; { : this is a target word ; } 2024-04-21 22:02:13 you need for some host words to appear in the target vocabulary, so for that i have a word "meta" to move the most recent definition into into the target space. e.g., : if { postpone 0branch >mark } ; meta 2024-04-21 22:03:55 but here's the dilemma: : variable create 0 , does> @ ; ( defines "variable" for the host) { : variable create 0 , does> @ ; } ( defines "variable" for the target) ... how do you write a host word that creates target words and defines their behavior with does>? 2024-04-21 22:06:33 i guess the target does> can be smart about whether the host compiler is active or the target compiler is active and then to the right thing accordingly. then you could write : variable { create 0 , does> @ ; } though that's a little weird because of the target ; at the end which is different from the host ; ... maybe that's ok 2024-04-21 22:06:39 this is complicated :( 2024-04-21 22:06:47 i don't like does> 2024-04-21 22:26:25 I've yet to use does> 2024-04-21 22:26:50 Damn is that the only comments anyone has? :) 2024-04-21 22:26:57 I must be pretty good at forth already! 2024-04-21 22:35:38 lf94: i'm by no means any forth authority, and i haven't looked at your implementation in detail, but just from a style standpoint, i think forthers would say you fell into the trap of writing forth like c. it's a very vertical style with long definitions. forth reads much clearer if you can break it into smaller definitions and write them horizontally with stack effect comments. 2024-04-21 22:36:59 ah, so your advice is, more words? :) 2024-04-21 22:37:11 yeah, i guess 2024-04-21 22:37:42 could you give me _one_ correction, to see what I should be doing? 2024-04-21 22:37:51 take a definition and make it more forthy 2024-04-21 22:42:15 lf94: 4c!, for example, which has an incorrect stack effect comment btw 2024-04-21 22:43:03 i might have written that like: : c!- ( c a1 -- a2) dup 1- -rot c! ; ( newline here) : 4c! ( b1 b2 b3 b4 a) 3 + c!- c!- c!- c! ; 2024-04-21 22:44:13 someone better at this could probably write it even better 2024-04-21 22:44:45 i mean, obviously by definition.. what i meant was, i'm sure there's probably an even better way to do it that someone else might see 2024-04-21 22:47:51 how's the stack effect comment wrong? 2024-04-21 22:47:56 b1 b2 b3 b4 addr -- 2024-04-21 22:48:21 store 4 8-bit values into addr 2024-04-21 22:48:47 I see what you mean though. Horizontal style preferred 2024-04-21 22:49:55 I think I'm thinking about performance also 2024-04-21 22:49:59 each word call is costly 2024-04-21 22:51:16 wow, thank you very much zelgomer 2024-04-21 22:51:25 I see now 2024-04-21 22:51:35 having a c! 2024-04-21 22:51:44 c!- really simplified it further 2024-04-21 22:52:21 iirc -rot is nonstandard 2024-04-21 22:52:24 i did this instead 2024-04-21 22:52:38 : c!- >r c! r> 1 - ; 2024-04-21 22:53:47 That won't work, the value on top of the return stack is the address it was called from 2024-04-21 22:54:35 : c!- tuck c! 1- ; 2024-04-21 22:56:45 what does tuck do again 2024-04-21 22:56:54 this is great stuff guys :) 2024-04-21 22:57:11 copies the top item under the second top item 2024-04-21 22:57:21 1 2 tuck -- 2 1 2 2024-04-21 22:59:39 i envy you when you use forth 2024-04-21 23:00:10 ah 2024-04-21 23:00:35 "the value on top of the retun stack is the address it wal called from" 2024-04-21 23:00:37 hm 2024-04-21 23:01:01 oh, I forgot to dup 2024-04-21 23:01:15 : c!- dup >r c! r> 1 - ; 2024-04-21 23:01:29 or 2024-04-21 23:01:38 : c!- >r r@ c! r> 1 - ; 2024-04-21 23:01:59 I feel >r r@ r> are more performance predictable than tuck, etc 2024-04-21 23:02:06 am I wrong? 2024-04-21 23:02:15 Using the return stack is really difficult to get right 2024-04-21 23:02:27 imo it's been pretty easy 2024-04-21 23:02:38 it's awesome to have it as a "result area" 2024-04-21 23:02:43 and all you do is make sure it's balanced, more or less 2024-04-21 23:03:13 But am I wrong about tuck, swap, etc having harder to determine cost than >r r@ r> ? 2024-04-21 23:03:49 Depends on implementation 2024-04-21 23:06:14 I suspect one tuck is going to be faster than three return stack operations though 2024-04-21 23:08:47 why's that? 2024-04-21 23:08:50 on an 8bit cpu? 2024-04-21 23:10:10 You might take a clue from Chuck's chips some of which have an a and b register for temp storage of values 2024-04-21 23:10:33 I'm thinking on really weak cpus 2024-04-21 23:10:38 But I can see on 32bit cpus yes 2024-04-21 23:10:41 ya return stack shenanigans are ok if you need an extra cell or two to stash things in a loop body or something but not much beyond that 2024-04-21 23:10:42 it being faster 2024-04-21 23:13:00 lf94 is usually faster to execute one word than three 2024-04-21 23:13:12 also it's likely tuck is a builtin 2024-04-21 23:19:16 ah true r> is still a call 2024-04-21 23:19:31 I'm thinking it's also a built-in and is just an access 2024-04-21 23:19:38 write/read 2024-04-21 23:19:58 yeah, not like you have to struggle too much with performance 2024-04-21 23:20:14 use the one that you like more or feels more correct 2024-04-21 23:26:41 lf94: by the way, : c!- >r r@ c! r> 1 - ; is also wrong, the value that's stored to memory is the return address 2024-04-21 23:26:45 personally, if tuck avoids me using r> i would prefer it 2024-04-21 23:27:21 lf94> how's the stack effect comment wrong? -- you're right, sorry. i saw you messing with the return stack and i thought you were getting addr from there. 2024-04-21 23:27:40 there's no harm as long as you restore everything before ending the colon execution, but if i already have a word that avoids it, i would go that way 2024-04-21 23:27:40 The problem with using the return stack is it's full of return addresses :P 2024-04-21 23:28:48 i also use it to store temp values like he is here, expecially during loops. but if i can, i usually try to get by without it. 2024-04-21 23:29:10 sometimes it's just cleaner to use it, though. like variables. 2024-04-21 23:30:28 lf94: sorry, I'm wrong about that c!- I keep mixing up >r and r> 2024-04-21 23:30:53 to-r and r-from :P 2024-04-21 23:31:40 that's another thing. for some reason i mix up >r and r>, too. and it's not a memory thing, i think it's a visual parsing thing. like a dyslexia with the r and the > 2024-04-21 23:32:03 and this is part of what i was talking about the other day about how i find naming things to be much more difficult in forth 2024-04-21 23:33:49 some folks have trouble getting the argument order to ln(1) or memcpy(3) right and always have to check le manual 2024-04-21 23:34:16 I always check the manual :| 2024-04-21 23:34:26 probably safer that way 2024-04-21 23:34:53 i usually get it right, but i confess i'm a habitual checker 2024-04-21 23:35:06 Maybe Smalltalk had the right idea with named parameters :P 2024-04-21 23:35:42 code-char and char-code can be tricky over in common lisp 2024-04-21 23:36:39 No silver bullet :/ 2024-04-21 23:37:18 if you use slime it helps 2024-04-21 23:39:14 GeDaMo: then we would just argue about what order to write them in by convention 2024-04-21 23:39:49 my toy lang is so different to any language that makes it even harder to read 2024-04-21 23:39:50 Smalltalk defines the order, you can't swap them around 2024-04-21 23:39:56 https://termbin.com/5vg3 2024-04-21 23:40:08 this is some playing i had with curses 2024-04-21 23:40:13 Well, when you define a method, you define the order, it's fixed 2024-04-21 23:40:32 it just binds all the keys to a movement and moves a # on the screen 2024-04-21 23:47:51 https://gist.github.com/lf94/dee5620369e3c6c2a8a5b69c9f9a044e 2024-04-21 23:47:55 building on gbforth :) 2024-04-21 23:48:25 20% of WRAM is definitely from that massive K[] allot 2024-04-21 23:51:13 :0 gbforth 2024-04-21 23:51:21 are you going to make a gb game? 2024-04-21 23:51:33 i saw that forth time ago 2024-04-21 23:51:59 probalby not going to make a gb game any time sono 2024-04-21 23:52:03 but this will def. help :) 2024-04-21 23:52:12 ive done gb asm in the past and while fun, it is time consuming 2024-04-21 23:52:19 can you not use constant in a def? 2024-04-21 23:52:41 https://gist.github.com/lf94/b392eee66fbd1d20a510e5ed46bc171a 2024-04-21 23:52:49 I'm trying to allot within a definition 2024-04-21 23:53:20 I guess I have to just push "here" onto the stack... 2024-04-21 23:54:38 I'll create K[] as a pointer instead 2024-04-21 23:54:51 create K[] 1 cells allot ( later on ... ) here K[] ! 2024-04-21 23:55:42 hell yea! 2024-04-21 23:55:48 \ 3756 bytes left, used 8% of WRAM 2024-04-21 23:57:20 I wonder if other forths tell you static memory usage 2024-04-21 23:57:25 awesome feature 2024-04-21 23:57:50 some might 2024-04-21 23:58:01 if you've seen a forth, you've seen a forth 2024-04-21 23:58:24 sad that my lang is an abomination instead :/