2024-03-24 00:33:20 <hello-operator> l
2024-03-24 04:32:44 <Al2O3       > have to say, I feel that SwiftForth is PH/FAT, 1288 words from the cli, amazingly big implementation.
2024-03-24 06:00:21 <lf94        > forth never "frees" memory right
2024-03-24 06:00:32 <lf94        > you just have to decide to go back and use it
2024-03-24 06:01:04 <lf94        > what's the maximum size of dictionaries?
2024-03-24 06:23:16 <lf94        > I dont get it
2024-03-24 06:23:24 <lf94        > im making my own s, right now because s, from gforth seems weird
2024-03-24 06:23:40 <lf94        > : s, here ! 1 cells allot here ! 1 cells allot ;
2024-03-24 06:23:54 <lf94        > create test s" hello world " s,
2024-03-24 06:23:57 <lf94        > what's wrong with this?
2024-03-24 06:24:17 <lf94        > it should store the string length followed by a string pointer
2024-03-24 06:27:37 <Al2O3       > you free memory :)
2024-03-24 06:28:01 <Al2O3       > or don't, and eventually you write better words and code/programs that make good use of stack based solutions.
2024-03-24 06:28:31 <Al2O3       > one of the better quotes is 'don't generalize'
2024-03-24 06:28:43 <Al2O3       > this thought, or approach may help, it may not.
2024-03-24 06:28:48 <Al2O3       > I hope it does.
2024-03-24 06:29:29 <lf94        > "you free memory"
2024-03-24 06:29:39 <lf94        > is that aka "move the here pointer" ?
2024-03-24 06:30:03 <lf94        > Is there a short form for 1 cells + @ ?
2024-03-24 06:30:23 <lf94        > <var> 1 cells + @
2024-03-24 07:01:01 <lf94        > wait a minute
2024-03-24 07:01:03 <lf94        > wait
2024-03-24 07:01:16 <lf94        > does forth have "noop" parens??
2024-03-24 07:01:29 <lf94        > because that could help with readability
2024-03-24 07:06:25 <dave0       > lf94: there is cell+ which could be defined as    : cell+ 1 cells + ;
2024-03-24 07:06:36 <lf94        > ah
2024-03-24 07:06:41 <lf94        > that's a nice one tbh
2024-03-24 07:30:24 <lf94        > A Forth with "subaddressing" would be SICK
2024-03-24 07:30:33 <lf94        > <cell address>:<bit address>
2024-03-24 07:30:57 <lf94        > BE6567AE4:6
2024-03-24 07:31:08 <lf94        > 6th bit of that address
2024-03-24 09:04:08 <veltas      > lf94:  : BIT@  >R @ R> RSHIFT 1 AND ;  : BIT!  SWAP >R  SWAP 1 AND  SWAP LSHIFT  R> ! ;   HEX  BE6567AE4 6 BIT@ .
2024-03-24 09:10:31 <dave0       > nice :-)
2024-03-24 09:10:42 <veltas      > Untested as ever
2024-03-24 09:10:55 <dave0       > bit store needs work
2024-03-24 09:11:44 <veltas      > Yeah you're right BIT! is nonsense
2024-03-24 09:11:45 <dave0       > oh it depends if you want to write a word with just the bit set, or you want to modify a single bit in a word
2024-03-24 09:12:11 <veltas      > Let's fix it
2024-03-24 09:12:34 <dave0       > you could break it into 2 words ... set a bit, or clear a bit
2024-03-24 09:15:15 <dave0       > : BIT0! 1 swap lshift invert over @ and swap ! ;
2024-03-24 09:15:37 <dave0       > : BIT1! 1 swap lshift over @ or swap ! ;
2024-03-24 09:16:02 <veltas      > : SET-BIT  1 SWAP LSHIFT  OVER @ OR  SWAP ! ;   : BIT!  ROT 1 AND IF SET-BIT  ELSE CLEAR-BIT  THEN ;   \ this is what I had so far
2024-03-24 09:16:06 <veltas      > Great minds think alike
2024-03-24 09:16:20 <dave0       > nice :-)
2024-03-24 09:16:35 <veltas      > Funny how you can get multiple people to write forth and get same result
2024-03-24 09:17:26 <dave0       > we could have a flame war over uppercase vs lowercase ;-)
2024-03-24 09:20:13 <veltas      > I don't even really see the difference
2024-03-24 09:20:39 <veltas      > Sometimes I think lowercase looks better but I think uppercase is easier to see amongst other text, makes it clearer what's code / not code
2024-03-24 09:25:28 <veltas      > The real flame war is 0BIT! vs BIT0!
2024-03-24 09:25:37 <veltas      > I think I'd prefer the former
2024-03-24 09:29:52 <veltas      > I think also there's opportunity for some useful factoring here, like  : AND!  TUCK @  AND  SWAP ! ;  and  : OR!  TUCK @  OR  SWAP ! ;
2024-03-24 09:29:55 <veltas      > Then you get  : 0BIT!  1 SWAP LSHIFT INVERT  SWAP AND! ;   : 1BIT!  1 SWAP LSHIFT  SWAP OR! ;
2024-03-24 09:38:43 <dave0       > cool
2024-03-24 12:18:24 <MrMobius    > you guys are assuming the architecture doesn't have a bit clear instruction
2024-03-24 15:36:24 <zelgomer    > lf94> does forth have "noop" parens??
2024-03-24 15:36:35 <zelgomer    > i like to call them comments
2024-03-24 15:38:44 <veltas      > lol
2024-03-24 15:39:00 <lf94        > you cant do this:
2024-03-24 15:39:14 <lf94        > 6 ( 3 3 +) +
2024-03-24 15:39:32 <zelgomer    > sure you can
2024-03-24 15:39:34 <lf94        > 3 3 + wont run
2024-03-24 15:39:49 <zelgomer    > correct, that is text inside of a comment
2024-03-24 15:39:50 <veltas      > : TEST   6  [: 3 3 + ;] EXECUTE + ;
2024-03-24 15:40:03 <lf94        > I want to be able to add parens or _something_ like this
2024-03-24 15:40:08 <lf94        > fo readability
2024-03-24 15:40:18 <lf94        > so my mind doesnt have to track boundaries
2024-03-24 15:40:20 <veltas      > Conventionally we use words for that
2024-03-24 15:40:29 <zelgomer    > or spaces
2024-03-24 15:40:33 <veltas      > Yeah
2024-03-24 15:40:43 <lf94        > 6 3 3 a b
2024-03-24 15:40:45 <zelgomer    > use two space to separate clauses
2024-03-24 15:40:48 <veltas      > So 6 ( 3 3 +) + can be:     : TEST  6  3 3 +  + ;
2024-03-24 15:40:48 <lf94        > oh
2024-03-24 15:40:54 <lf94        > ohhhh shit
2024-03-24 15:40:56 <lf94        > ok
2024-03-24 15:41:05 <lf94        > thank you for that; yep that's much better
2024-03-24 15:41:25 <veltas      > Or   : TEST' 3 3 + ;  : TEST  6 TEST' + ;
2024-03-24 15:42:25 <veltas      > The [: ;] syntax earlier is called a quotation, it's a word within a word.  But syntactically it's completely pointless as this is a concatenative language so using the extra spaces makes more sense
2024-03-24 15:42:26 <zelgomer    > or i've been known to even do  : test  3 3 + ;  : test  6 test + ;  does this make me a bad person?
2024-03-24 15:42:33 <veltas      > Not at all
2024-03-24 15:42:45 <veltas      > I like that convention but it makes it harder to trawl with SEE/LOCATE
2024-03-24 15:42:49 <veltas      > Only downside
2024-03-24 15:43:21 <veltas      > Like it's not very helpful to run SEE and get some self-referential half-complete definition
2024-03-24 15:43:49 <veltas      > This is already a problem with packages like I use though, so not new
2024-03-24 15:44:10 <veltas      > Vanilla SEE actually isn't very helpful, it always needs special alternatives or helpers
2024-03-24 15:45:03 <veltas      > Not to say quotations are pointless in general, just pointless if you're going to run EXECUTE on the result
2024-03-24 15:45:56 <veltas      > lf94: If you read Starting Forth there's some good examples of code style in there
2024-03-24 15:46:19 <veltas      > Also Thinking Forth has lots more examples, although some of the advice in there is too strict IMO
2024-03-24 16:01:11 <lf94        > I care more about what you experience forth peeps do ;)
2024-03-24 16:01:25 <lf94        > I'm having some weird issue with cmove>
2024-03-24 16:01:31 <lf94        > maybe someone can spot it
2024-03-24 16:02:53 <lf94        > https://gist.github.com/lf94/0df557392db8c3a5fc684369257da004#file-sha256-f-L97
2024-03-24 16:03:17 <lf94        > ok @ \ value is the length as expected
2024-03-24 16:03:29 <lf94        > (I realize the value should be 64 but ignore this for now)
2024-03-24 16:03:51 <lf94        > ok 1 cells + @ c@ \ doesn't seem right. returns 104
2024-03-24 16:04:14 <lf94        > ok 2 cells + c@ \ also returns 104, which means at the very least things are pointing to the correct place.
2024-03-24 16:04:25 <lf94        > (I place the new message right after the pointer to it
2024-03-24 16:05:01 <lf94        > in dictionary it shouldl ook like this: [length][ptr-to-msg][msg] - I do this so I can use words like `type` still etc
2024-03-24 16:11:00 <GeDaMo      > I'm not sure how 'type' is related to that
2024-03-24 16:12:26 <veltas      > Don't store to HERE
2024-03-24 16:13:10 <veltas      > That area is often used by buffers etc, not really portable to store there, never know when something will use it.  Officially parsing can put parsed text in that area for instance
2024-03-24 16:13:22 <veltas      > I doubt that's the problem though
2024-03-24 16:13:32 <lf94        > im storing to "HERE" because message could be massive
2024-03-24 16:14:07 <veltas      > I'm saying do the allot before the store
2024-03-24 16:14:22 <veltas      > You can do   HERE  1 CELLS ALLOT  !
2024-03-24 16:14:25 <veltas      > or similar
2024-03-24 16:14:29 <lf94        > /oh/
2024-03-24 16:14:34 <veltas      > Just good practice, probably doesn't matter here as I saide
2024-03-24 16:14:42 <veltas      > As it's all compiled so no parsing going on mid-word
2024-03-24 16:14:57 <lf94        > I guess my mental model of storing is not rigth
2024-03-24 16:14:59 <lf94        > like
2024-03-24 16:15:01 <lf94        > the order it stores in
2024-03-24 16:15:14 <veltas      > ! stores where it appears
2024-03-24 16:15:16 <lf94        > I thought it stores "left to right", i.e. here = 0, fill up bytes from 0 to n
2024-03-24 16:15:29 <veltas      > If you want to store a cell to dictionary just use ,
2024-03-24 16:15:52 <veltas      > Dictionary grows up, not down
2024-03-24 16:16:08 <veltas      > Dictionary is a bit like a stack but it grows up so you can build arrays in order
2024-03-24 16:16:12 <lf94        > oh I see what you mean about 1 cells allot
2024-03-24 16:17:04 <lf94        > I think
2024-03-24 16:17:32 <lf94        > GeDaMo: type lets me see the string I stored lol
2024-03-24 16:17:49 <veltas      > I think GeDaMo's wondering why you'd need to store the pointer
2024-03-24 16:18:03 <lf94        > to be in line with this...:
2024-03-24 16:18:03 <veltas      > You can calculate the pointer to buffer before using TYPE
2024-03-24 16:18:10 <lf94        > https://gforth.org/manual/String-representations.html#:~:text=Counted%20strings%20are%20limited%20to%20255%20bytes%20in%20length.
2024-03-24 16:18:23 <lf94        > > Forth commonly represents strings as cell pair c-addr u on the stack; u is the length of the string in bytes (aka chars), and c-addr is the address of the first byte of the string. Note that a code point may be represented by a sequence of several chars in the string (and a Unicode “abstract character” may consist of several code points). See String words.
2024-03-24 16:18:56 <lf94        > I think I botched the order but still
2024-03-24 16:20:33 <lf94        > Im pretty sure my cmove> is just messed up
2024-03-24 16:22:04 <GeDaMo      > I suppose you can use 2@ to get the length and pointer
2024-03-24 16:23:42 <veltas      > If you store length in a whole cell before the string then the string address is at CELL+ from the length address
2024-03-24 16:23:50 <veltas      > And you can use more than 255 chars
2024-03-24 16:24:06 <veltas      > lf94 don't be afraid of the return stack
2024-03-24 16:24:18 <veltas      > Also use -ROT
2024-03-24 16:24:24 <veltas      > gforth and most forths have it
2024-03-24 16:26:15 <lf94        > veltas: yes I do cell+
2024-03-24 16:26:27 <lf94        > note I'm avoiding "composed words" like cell+
2024-03-24 16:26:34 <lf94        > just to get familiar with the lower level stuff
2024-03-24 16:26:46 <lf94        > yes the length is a whole cell
2024-03-24 16:26:48 <veltas      > cmove> expects two addresses to move stuff between
2024-03-24 16:26:57 <lf94        > also nice about -rot - i was wondering how the hell I rotate the other way :)
2024-03-24 16:27:04 <lf94        > yes it has two
2024-03-24 16:27:08 <lf94        > from to u
2024-03-24 16:27:15 <lf94        > put a .S before it you'll see
2024-03-24 16:27:26 <veltas      > Usually pronounced "minus rot" I think
2024-03-24 16:29:53 <GeDaMo      > On line 105 are you storing a byte value or a cell there?
2024-03-24 16:30:12 <lf94        > :).
2024-03-24 16:30:15 <lf94        > you got it
2024-03-24 16:30:19 <lf94        > should be c!
2024-03-24 16:30:38 <GeDaMo      > You can just use c, in place of here c! 1 allot
2024-03-24 16:30:39 <lf94        > I wish characters where called bytes
2024-03-24 16:30:46 <lf94        > in my forth c! will be b! :p
2024-03-24 16:30:59 <GeDaMo      > You can always define your own b!
2024-03-24 16:31:00 <lf94        > ah yea. im doing it out of practice
2024-03-24 16:31:29 <lf94        > I know there are perf. benefits and it's less to read but right now I need all that out on the table
2024-03-24 16:32:33 <veltas      > Also you're writing to HERE with CMOVE> which again isn't extremely portable, better to ALLOT before the CMOVE> happens
2024-03-24 16:34:09 <lf94        > I honestly don't get why
2024-03-24 16:34:22 <lf94        > cmove's target is constant isnt it
2024-03-24 16:34:27 <lf94        > where i do "here"
2024-03-24 16:35:00 <GeDaMo      > There's always the possibility that something else might write to here between the cmove> and the allot
2024-03-24 16:35:16 <lf94        > couldnt somethnig write to here between the here and the allot too?
2024-03-24 16:35:22 <lf94        > I guess that's my point of "stuck"
2024-03-24 16:35:31 <veltas      > Yeah like if an interrupt/signal happens it might write to that area in dictionary space because it's unallocated
2024-03-24 16:35:43 <GeDaMo      > If you allot first, then the memory is allocated before you copy to it
2024-03-24 16:35:47 <veltas      > ^
2024-03-24 16:36:05 <veltas      > And outside of compiled words, you will clobber that area by parsing on many forths
2024-03-24 16:36:08 <lf94        > oh. in my mind, it was already allocated before hand
2024-03-24 16:36:11 <lf94        > oh shit I completely see now
2024-03-24 16:36:20 <lf94        > jesus, im thinking of forth like javascript
2024-03-24 16:36:27 <lf94        > very wrong
2024-03-24 16:36:43 <veltas      > lol no problem
2024-03-24 16:37:08 <veltas      > If anything I'm impressed that someone's going from JS to Forth, more challenging than C to Forth
2024-03-24 16:38:50 <veltas      > Like some old forths literally parse words to the location that the next compiled word label would go, so that : doesn't need to do an extra copy
2024-03-24 16:40:36 <veltas      > On those systems the address of parsed words is something like  : 'WORD  HERE CELL+ ;
2024-03-24 16:40:37 <lf94        > well I corrected a bunch
2024-03-24 16:41:08 <lf94        > veltas: JS is just my "lisp". I'm a low level hacker at heart
2024-03-24 16:41:16 <lf94        > I do webdev to pay the bills
2024-03-24 16:41:46 <lf94        > Ive done x86_64, mips, gameboy assembly, C, Rust
2024-03-24 16:42:00 <veltas      > Yeah I learned a lot about Z80 from a webdev that writes stuff for ZX Spectrum in their free time
2024-03-24 16:42:30 <lf94        > corrected stuff https://gist.github.com/lf94/0df557392db8c3a5fc684369257da004#file-sha256-f-L98
2024-03-24 16:42:37 <lf94        > but still the same results surprisingly
2024-03-24 16:42:54 <lf94        > (i know the allot wouldntve changed anything)
2024-03-24 16:43:03 <veltas      > Yeah probably not
2024-03-24 16:43:21 <lf94        > but I switched out a few ! for c!
2024-03-24 16:43:41 <veltas      > On a little endian system (most systems are little endian) if you ! instead of C! but you're writing in increasing order of addresses there'll be no difference
2024-03-24 16:43:51 <veltas      > Well it clobbers what comes after but in dictionary it won't matter
2024-03-24 16:45:37 <GeDaMo      > lf94: what problems are you encountering?
2024-03-24 16:47:15 <lf94        > I'm seeing "104" decimal for the letter "h"
2024-03-24 16:47:23 <lf94        > im an idiot
2024-03-24 16:47:44 <GeDaMo      > h is 104 :|
2024-03-24 16:47:53 <lf94        > mindfuck moment
2024-03-24 16:47:54 <veltas      > EMIT prints a character
2024-03-24 16:48:04 <lf94        > I have one small terminal I was running `ascii` in
2024-03-24 16:48:17 <lf94        > and I saw 104 was way outta range
2024-03-24 16:48:32 <lf94        > or somethnig
2024-03-24 16:48:34 <lf94        > im tired
2024-03-24 16:48:52 <lf94        > when I made the terminal larger just now and re-ran it I instantly see it's h
2024-03-24 16:48:54 <lf94        > lol
2024-03-24 16:49:39 <GeDaMo      > gforth has a 'dump' word which shows a hexdump from ( addr n -- )
2024-03-24 16:50:54 <veltas      > Also in standard forth you'd need to write   CHAR " PARSE hello "   in that test, because S" is allowed to put the string in the dictionary where you're trying to allocate in your word
2024-03-24 16:51:02 <veltas      > I think gforth just malloc()s every S"
2024-03-24 16:51:12 <veltas      > And leaks all of them, because why not
2024-03-24 16:52:07 <veltas      > Or    '"' PARSE hello "   if your forth supports character literals
2024-03-24 16:53:05 <veltas      > dump is great for exploring the layout of a new forth
2024-03-24 16:53:33 <veltas      > That's why the screenshot of zenv uses dump, it's the first thing I do on a new forth
2024-03-24 16:54:33 <lf94        > ensuring the value length is stored as a 64 bit num is a bit annoynig
2024-03-24 16:55:03 <lf94        > since i want this to work on zenv
2024-03-24 16:55:15 <lf94        > im looking at restricting message length to 255 chars
2024-03-24 16:55:19 <veltas      > Here's an idea
2024-03-24 16:55:25 <veltas      > Write it for a 32-bit or 64-bit forth
2024-03-24 16:56:25 <veltas      > It might be easier to just change the relevant core words to use 32-bit or 64-bit values on a 16-bit forth once for all programs, than try to support 64-bit in one 16-bit program
2024-03-24 16:57:07 <veltas      > Someone just needs to write some words for doubling up the precision, which probably isn't too hard, as long as the mixed and double precision words are available
2024-03-24 16:57:10 <veltas      > Which they are on zenv
2024-03-24 16:57:33 <veltas      > Rome wasn't built in a day
2024-03-24 16:58:06 <veltas      > And if those words double up your precision you can load them twice on zenv to get a 64-bit forth
2024-03-24 17:00:26 <veltas      > Even most MCU's now are 32-bit, so not a lot of value supporting 16-bit.  Probably not too hard to write a 32-bit forth for ZX Spectrum
2024-03-24 17:01:58 <GeDaMo      > You can also write your own application specific store / retrieve words and map them to the implementation
2024-03-24 17:02:54 <veltas      > Yeah but how to manipulate a 64-bit value in a 16-bit forth?
2024-03-24 17:03:17 <thrig       > slowly?
2024-03-24 17:03:44 <veltas      > Can have Q+! etc operating on addresses on the stack but this just feels wrong anyway
2024-03-24 17:04:12 <lf94        > ok 1 cells + @ 63 + c@  ok
2024-03-24 17:04:14 <lf94        > . 6  ok
2024-03-24 17:04:16 <lf94        > hell yea
2024-03-24 17:05:14 <lf94        > I'm going to keep it restricted to 255 len for now
2024-03-24 17:05:39 <lf94        > actually...
2024-03-24 17:05:41 <lf94        > blah
2024-03-24 17:05:45 <lf94        > cells to the rescue
2024-03-24 17:06:13 <veltas      > perfect cells
2024-03-24 17:07:08 <veltas      > Q1+! Q1-! Q@0= probably all you need for length measurement, not too slow
2024-03-24 17:07:34 <veltas      > Well I don't know how SHA256 works so maybe you need more
2024-03-24 17:08:11 <lf94        > yeah the weird case is between <system bit width> and <8 bit width> :p
2024-03-24 17:09:39 <lf94        > ok, PHEW, done pre-processing. LOL
2024-03-24 17:21:48 <veltas      > Yeah SHA256 you've bitten off a lot there
2024-03-24 17:22:42 <veltas      > Most of us are scratching our heads here trying to do really simple things and you're writing crypto hashes :P
2024-03-24 17:23:08 <veltas      > Although it's not actually complicated but just a bit tedious maybe for a first exercise
2024-03-24 17:30:22 <lf94        > It's how I learn
2024-03-24 17:30:40 <lf94        > yeah it isnt so bad
2024-03-24 17:30:43 <lf94        > im just breaking it all down
2024-03-24 17:30:59 <lf94        > I gotta use return stack more like you said
2024-03-24 17:31:15 <lf94        > I'm going to create some "32 bit" words
2024-03-24 17:31:23 <lf94        > 32@, 32rr, 32rs, 32xor, etc
2024-03-24 17:31:49 <veltas      > Why not just use double words?
2024-03-24 17:31:58 <veltas      > double/mixed
2024-03-24 17:32:03 <veltas      > Like D+ M* et al
2024-03-24 17:32:31 <veltas      > Probably because you've not read starting forth yet but I'll admit there's real problems too like doubles can be bigger than 32-bit
2024-03-24 17:33:08 <lf94        > https://gist.github.com/lf94/0df557392db8c3a5fc684369257da004
2024-03-24 17:33:09 <veltas      > And there aren't a lot of double bitwise words
2024-03-24 17:33:44 <lf94        > from what I understand it's best to assume i'm always on an 8 bit platform forth :P
2024-03-24 17:34:18 <veltas      > 8-bit CPU forths tend to support 32-bit operations with double words
2024-03-24 17:35:05 <veltas      > bitwise ops you don't need to up-size, just shifts/rotates need to support bigger sizes
2024-03-24 17:47:13 <lf94        > 32dup, 32@, 32rr and 32s coming right up
2024-03-24 17:47:28 <lf94        > you need 32xor because the program needs to know to do xor 4 times
2024-03-24 17:51:40 <lf94        > is there a way to tell forth "stop here"
2024-03-24 17:51:42 <lf94        > quit here
2024-03-24 17:51:44 <lf94        > whatever
2024-03-24 17:52:46 <lf94        > > exit
2024-03-24 17:53:14 <lf94        > oh, "bye"
2024-03-24 17:54:02 <thrig       > I usually alias that to exit or q
2024-03-24 17:55:52 <veltas      > QUIT and ABORT stop the program or exit loading a source file
2024-03-24 17:56:00 <veltas      > BYE is more like "get me out of forth"
2024-03-24 17:56:28 <veltas      > QUIT goes back to the main interpreter and clears return stack.  ABORT also clears the data stack
2024-03-24 17:57:06 <veltas      > In forths that support exceptions ABORT is essentially something like  -1 THROW
2024-03-24 17:59:41 <lf94        > this is so dope
2024-03-24 18:00:05 <lf94        > https://gist.github.com/lf94/252e09f8d2e740ae15a8d378c69f0ecc
2024-03-24 18:00:20 <lf94        > works perfectly
2024-03-24 18:00:51 <lf94        > I take it back c! should be 8!
2024-03-24 18:01:00 <lf94        > ! should be "system bit widtH"
2024-03-24 18:01:13 <lf94        > know what f it im going to define it :p
2024-03-24 18:08:05 <lf94        > forth is actually so beautiful
2024-03-24 18:08:15 <lf94        > because you make it fit what your definition of code beauty is
2024-03-24 18:12:22 <lf94        > 32dup feeling tricky
2024-03-24 18:25:12 <veltas      > Yeah I wouldn't necessarily put it on the stack
2024-03-24 18:26:41 <veltas      > Forth's strongsuit is not big mathematical or cryptographic calculations
2024-03-24 18:26:49 <veltas      > Especially not if you want to write portable code
2024-03-24 18:34:06 <thrig       > but you can have some fun with a PRNG, https://thrig.me/tmp/jenkins-small-fast-8bit-rng.txt
2024-03-24 19:00:17 <lf94        > veltas: I realize needing a "register" is necessary
2024-03-24 19:00:31 <lf94        > "forth's strongsuit is not big math calculations" why not? :)
2024-03-24 19:00:49 <lf94        > I was looking into the origin of polish notation
2024-03-24 19:00:59 <lf94        > and then reverse polish notation
2024-03-24 19:01:10 <lf94        > It's literally a better mathematical notation.
2024-03-24 19:01:25 <lf94        > we are just not used to it
2024-03-24 19:01:49 <lf94        > I did a few algebriac problems on paper with it
2024-03-24 19:01:54 <lf94        > It's completely ok
2024-03-24 19:03:12 <thrig       > mathy things! https://thrig.me/tmp/mathy.txt
2024-03-24 19:03:31 <lf94        > seems like I should just do 32@ twice.
2024-03-24 19:04:25 <lf94        > your usage of r@ is interesting!
2024-03-24 19:04:31 <lf94        > that's not a pattern ive encountered yet
2024-03-24 19:05:49 <lf94        > god this is a great pattern
2024-03-24 19:06:21 <thrig       > another option would be a local variable instead of return stack fiddling
2024-03-24 19:06:55 <lf94        > nah return stack is better
2024-03-24 20:23:43 <lf94        > using indentation to know how many items on the stack: useful
2024-03-24 20:26:29 <lf94        > https://gist.github.com/lf94/a7d314b3425b9e1d86f3332c97ac81e1
2024-03-24 20:26:32 <lf94        > almost there
2024-03-24 20:36:06 <joe9        > I suspect that one should not be writing such big routines in forth.
2024-03-24 20:36:38 <joe9        > It is painful to decipher or test.
2024-03-24 20:43:12 <lf94        > Oh Im writing in little chunks at a time
2024-03-24 20:43:20 <lf94        > but yes
2024-03-24 20:55:25 <lf94        > Did it :)
2024-03-24 20:55:32 <lf94        > I'm 100% open to suggestions on workflow here
2024-03-24 20:55:48 <lf94        > I'm find it hard, at least in this circumstance, to work in words
2024-03-24 20:56:42 <lf94        > https://gist.github.com/lf94/a7d314b3425b9e1d86f3332c97ac81e1 boom
2024-03-24 20:57:08 <lf94        > I would rather "unrepeat" myself after I see it working
2024-03-24 21:22:36 <lf94        > i simplified it further
2024-03-24 21:22:38 <lf94        > I love this
2024-03-24 21:23:04 <lf94        > https://gist.github.com/lf94/a7d314b3425b9e1d86f3332c97ac81e1
2024-03-24 21:24:15 <lf94        > only xor left B)
2024-03-24 21:59:50 <lf94        > Im stuck back on rotate because I was dumb and didn't realize I was rotating the same data
2024-03-24 21:59:56 <lf94        > it has to be a rotate that saves the old data
2024-03-24 22:00:52 <joe9        > have you read "Starting Forth" and "Thinking Forth"
2024-03-24 22:00:53 <joe9        > ?
2024-03-24 22:01:18 <joe9        > it will be painful to maintain. The code is how a C programmer would write Forth.
2024-03-24 22:02:01 <joe9        > Remember, if there a subroutine is using more than 2-3 parameters on the stack, it is way too big.
2024-03-24 22:02:40 <joe9        > Color Forth does not even have rotate. If it is well structured code, it should not need "rotate".
2024-03-24 22:03:57 <joe9        > Try to use variables instead of the stacks to maintain temporary state.
2024-03-24 22:04:53 <lf94        > i'm dealing with 32 bit values
2024-03-24 22:04:55 <lf94        > specifically
2024-03-24 22:05:00 <lf94        > It's to implement SHA256
2024-03-24 22:05:12 <lf94        > on an 8 bit cpu that veltas wrote a forth fro
2024-03-24 22:05:14 <lf94        > for
2024-03-24 22:05:20 <joe9        > sha256 should be in assembly, imo.
2024-03-24 22:06:20 <joe9        > Writing code like that in Forth defeats the purpose of code.
2024-03-24 22:06:25 <joe9        > s/code/Forth/
2024-03-24 22:06:48 <joe9        > Sorry if I am coming across as rude.
2024-03-24 22:07:32 <lf94        > hahah not at all! i completely understand
2024-03-24 22:08:09 <lf94        > In this case it may actually be equally as difficult or easy to be doing this in Forth or Assembly
2024-03-24 22:08:18 <lf94        > Because we're dealing with simulating larger numbers on a small bit CPU
2024-03-24 22:08:59 <joe9        > In my opinion, that code will be as good as gibberish in 2 weeks.
2024-03-24 22:16:54 <Zarutian_iPad> lf94: what is that sha256 implementation for?
2024-03-24 22:17:09 <lf94        > for learning
2024-03-24 22:17:51 <Zarutian_iPad> kewl. Heard about macaroons or chained hmac constructions?
2024-03-24 22:40:19 <Zarutian_iPad> lf94: you calculating the 'nothing up my sleave' number constants from scratch or just using the provided constants?
2024-03-24 22:40:55 <lf94        > just using the provided ones
2024-03-24 22:45:04 <lf94        > I almost have all rotation happening on the stack
2024-03-24 22:46:39 <lf94        > swap and return stack can do incredible things
2024-03-24 23:29:48 <lf94        > holy hell
2024-03-24 23:29:50 <lf94        > I did it
2024-03-24 23:30:24 <lf94        > https://gist.github.com/lf94/3b4ae2bd07680243dd3842a111f2f56a
2024-03-24 23:31:25 <lf94        > It's honestly easier to understand not hiding stuff behind words
2024-03-24 23:32:22 <lf94        > Pretty excited to see this run on zenv
2024-03-24 23:32:27 <lf94        > and whatever else
2024-03-24 23:34:30 <lf94        > Im not that far off from completing the whole thing imo
2024-03-24 23:34:36 <lf94        > need a 32and, 32not
2024-03-24 23:34:41 <lf94        > 32xor still
2024-03-24 23:34:45 <lf94        > but the rest is just glue
2024-03-24 23:35:56 <lf94        > ooof need a 32add also
2024-03-24 23:36:04 <lf94        > guess i'll call it 32+
2024-03-24 23:37:37 <lf94        > you're all disgusted by my sick use of the stack
2024-03-24 23:37:44 <lf94        > but i think it's great
2024-03-24 23:38:02 <lf94        > (said tongue-in-cheek)
2024-03-24 23:39:38 <lf94        > when does does> become useful? :p
2024-03-24 23:42:34 <zelgomer    > when you want to templatize the creation of new words
2024-03-24 23:43:02 <zelgomer    > i'm on the fence about does>. i use it from time to time, but tbh it doesn't do anything that you couldn't do with simple composition.
2024-03-24 23:46:22 <zelgomer    > lf94: simplest example would be something like   : numberprinter ( n ccc)  create , does>  @ . ;   42 numberprinter forty-two  69 numberprinter sixty-nine;););)  now when you enter "forty-two" it will print 42, and when you enter "sixty-nine;););)" it will print 69.
2024-03-24 23:46:56 <zelgomer    > it defines action that occurs when the most recently "create"d word is executed
2024-03-24 23:47:47 <lf94        > ah
2024-03-24 23:47:57 <lf94        > yea why not just... make that part of the word
2024-03-24 23:48:19 <lf94        > : numberprinter create , ( do more stuff ) ;
2024-03-24 23:48:29 <lf94        > xor -> done
2024-03-24 23:48:48 <zelgomer    > because your ( do more stuff ) runs when numberprinter executes, not when the created word executes
2024-03-24 23:49:27 <zelgomer    > to achieve the same result without does> looks like   : numberprinter  . ;   : forty-two  42 numberprinter ;
2024-03-24 23:49:59 <zelgomer    > the does> form may be more compact in memory
2024-03-24 23:50:38 <lf94        > oh
2024-03-24 23:50:54 <lf94        > I mean I think I prefer when we avoid unnecessary abstractions
2024-03-24 23:51:13 <zelgomer    > constant can be defined in terms of does>
2024-03-24 23:51:20 <zelgomer    > : constant  create , does>  @ ;
2024-03-24 23:51:32 <zelgomer    > just as another example
2024-03-24 23:51:38 <lf94        > I thought create was defined using constant :V
2024-03-24 23:51:54 <lf94        > "not" is just -1 * right
2024-03-24 23:52:28 <lf94        > appears not
2024-03-24 23:52:36 <zelgomer    > not would be -1 xor
2024-03-24 23:52:52 <zelgomer    > -1 * is usually called negate. i tend to call it -1*
2024-03-24 23:53:27 <lf94        > right rgiht
2024-03-24 23:53:31 <lf94        > cool, that was easy
2024-03-24 23:53:34 <lf94        > onto the last one! 32+
2024-03-24 23:53:45 <lf94        > this one will be a bit tricky like 32rr
2024-03-24 23:53:49 <lf94        > because of carry bits
2024-03-24 23:56:30 <lf94        > I'll save it for tomorrow I think
2024-03-24 23:56:34 <lf94        > or much later
2024-03-24 23:59:29 <lf94        > god
2024-03-24 23:59:40 <lf94        > so much overhead I think to check carry bits / overflow