2024-03-19 11:34:02 <veltas      > GeDaMo: I've read the 2010 PEG front/middle/back paper
2024-03-19 11:34:19 <veltas      > Nice if you like PEGs, what can I say
2024-03-19 11:34:44 <veltas      > Are there any papers on Forth's compiler?
2024-03-19 12:02:49 <GeDaMo      > Which Forth compiler?
2024-03-19 12:33:34 <skvery      > veltas  You can look at Mecrisp for a efficient Forth interpreter.
2024-03-19 13:21:33 <veltas      > nVidia AI chip Forth when?
2024-03-19 14:31:06 <veltas      > Okay I've got a 'locals' concept for forth, I'm sure nobody wants this
2024-03-19 14:31:32 <veltas      > HFIELD:   which is like  FIELD:  but goes backwards, producing negative offsets, and automatically bases from HERE
2024-03-19 14:32:02 <veltas      > At the end you get a value to ALLOT and you can access fields implicitly at the end of data area
2024-03-19 14:32:33 <veltas      > Can give these fields names like vars and put them in private scope (so private wordlist package, vocab, or smudge the defs later, however you want to do this)
2024-03-19 14:33:29 <veltas      > So e.g.  0  HFIELD: X  CONSTANT %TEST    then %TEST is 4, and X gives the address HERE 4 -
2024-03-19 14:33:55 <veltas      > You can then do e.g. %TEST ALLOT   ... X !  ... X @    0 %TEST - ALLOT ;
2024-03-19 14:34:27 <veltas      > on a 32-bit forth for example
2024-03-19 14:35:39 <veltas      > Looks like someone's bundled new gforth on snap
2024-03-19 14:44:57 <zelgomer    > veltas: don't know if i have any use for it right now, but i like it
2024-03-19 14:45:09 <zelgomer    > i have ideas too that sound good in my head but i'm pretty sure nobody wants :)
2024-03-19 14:49:56 <veltas      > : -HFIELD ( nn"-n)  + DUP >R :  POSTPONE HERE  R> POSTPONE LITERAL  POSTPONE -  POSTPONE ;  ;
2024-03-19 14:50:00 <veltas      > : HCFIELD: 1 -HFIELD ;
2024-03-19 14:50:04 <veltas      > : HFIELD: ALIGNED CELL -HFIELD ;
2024-03-19 14:50:12 <veltas      > The whole library ^
2024-03-19 14:50:23 <veltas      > Defined with ugly POSTPONE for better performance in optimising forths
2024-03-19 14:50:32 <veltas      > Can use DOES> if you don't care
2024-03-19 14:52:26 <veltas      > : -HFIELD ( nn"-n)  +  CREATE DUP NEGATE , DOES>  @ HERE + ;   \ DOES> version
2024-03-19 14:53:36 <veltas      > Thanks zelgomer
2024-03-19 14:54:49 <veltas      > I came up with this thinking about how I would do SHA256, still waiting on that from lf94
2024-03-19 14:56:43 <veltas      > So I can do something like this: https://pastebin.com/raw/P80MR7ec
2024-03-19 15:40:45 <veltas      > GeDaMo: There are some aspects that are common to almost all forth compilers, but papers on specific early forths would be interesting too
2024-03-19 15:44:51 <zelgomer    > veltas: why this "0 %SHA256 -" idiom and not "%SHA256 NEGATE" ?
2024-03-19 15:52:25 <veltas      > Less characters
2024-03-19 15:52:43 <GeDaMo      > veltas: do you know the book "Threaded Interpretative Languages"? It's about an implementation on a Z80
2024-03-19 15:52:54 <veltas      > No, sounds interesting
2024-03-19 15:53:07 <GeDaMo      > https://archive.org/details/R.G.LoeligerThreadedInterpretiveLanguagesTheirDesignAndImplementationByteBooks1981
2024-03-19 15:58:39 <veltas      > I think also it might be cool to add a REGISTER: word that does the same as HFIELD:, but explicitly uses a register if enough are available
2024-03-19 15:58:59 <veltas      > Resurrect the 'register' keyword from C basically lol
2024-03-19 15:59:21 <GeDaMo      > A register‽ on a stack machine‽ :P
2024-03-19 15:59:30 <veltas      > Do e.g.   REGISTER X@ X!  to define get/set words for the register, cannot take its address
2024-03-19 16:00:18 <veltas      > Forths need not be scared of the machine :)
2024-03-19 16:00:47 <veltas      > And you can put these vars in order of preference for getting those precious registers
2024-03-19 16:02:14 <veltas      > Need a special word to (de)allocate though, to save/restore registers, assuming we'll use callee-saved registers
2024-03-19 16:04:55 <veltas      > Just remember, Forth is the real "portable assembly"
2024-03-19 16:07:43 <zelgomer    > i disagree. forth is a vm.
2024-03-19 16:08:43 <zelgomer    > the compiler /might/ map it to native machine code, but that's a different matter
2024-03-19 16:13:52 <veltas      > I'm just making a joke about how people call C the portable assembly
2024-03-19 16:14:32 <zelgomer    > oh yeah, sorry
2024-03-19 16:14:39 <veltas      > Certainly a forth can be portable assembly if you want it to be, but that's not all forths yeah
2024-03-19 16:15:33 <zelgomer    > speaking of, i actually find it very disappointing that you can't get a double precision result from a single precision multiplication in c without gimmicks
2024-03-19 16:15:52 <zelgomer    > does there exist a processor on earth with a mul instruction that doesn't output a double precision product?
2024-03-19 16:17:18 <veltas      > I think ARM has some embedded CPUs that do 32x32->32 only
2024-03-19 16:18:13 <zelgomer    > even in that case, the standard could say "when the alu doesn't support it, the product's high word will be 0" or something
2024-03-19 16:18:17 <veltas      > Just reducing transistor count a tiny bit, taking advantage of fact that C doesn't care anyway
2024-03-19 16:19:16 <veltas      > The way to do it with a good C compiler is convert the arguments to the larger type
2024-03-19 16:19:37 <veltas      > GCC has got __uint128 etc for this exact purpose it seems, as they're not even supported on 32-bit
2024-03-19 16:19:46 <veltas      > and it will generate a single MUL for it
2024-03-19 16:22:10 <zelgomer    > but that's the thing, now you have to rely on extensions and compiler magic to do the right thing
2024-03-19 16:22:51 <veltas      > Yeah the standard lets you down
2024-03-19 16:23:24 <veltas      > For the sake of practicality I insist on assuming GCC at work for C projects
2024-03-19 16:23:47 <zelgomer    > yeah, where i work pretty much does the same
2024-03-19 16:23:58 <zelgomer    > but now we've given those gnu bastards power :)
2024-03-19 16:24:21 <veltas      > those GNU fatcats
2024-03-19 16:26:01 <veltas      > But yeah it is nice that we have UM* M* M/ etc or equivalent in most forths
2024-03-19 16:31:30 <zelgomer    > i've written fixed point stuff in c and it's deceptively annoying because of this type of stuff
2024-03-19 16:32:20 <zelgomer    > so when the standard lets me down, what do i do? turn to a language with no standard
2024-03-19 16:32:28 <zelgomer    > and my own implementation
2024-03-19 16:32:30 <zelgomer    > totally makes sense