2024-06-18 01:24:08 <KipIngram   > Floating point can bite you in some interesting ways.
2024-06-18 05:50:49 <KipIngram   > That's interesting that Von Neumann didn't like it.
2024-06-18 05:51:24 <KipIngram   > Of course Chuck doesn't like it either; I think it just moves some things further from the programmer than he likes.
2024-06-18 05:51:47 <KipIngram   > It is, after all, a facility designed to make it less necessary for you to think about what your code is doing.
2024-06-18 05:52:02 <KipIngram   > Well, aspects of what your code is doing.
2024-06-18 10:20:21 <veltas      > KipIngram: And this is why we haved fixed point notation in forth, e.g. 1.000 is 1000 0 , because we're being kind and giving the best possible syntax for fixed point work
2024-06-18 10:20:46 <veltas      > Any language can choose to do this at any time, but it just means when you *multiply* or *divide* you need to remember to use a muldiv function instead
2024-06-18 10:21:16 <veltas      > e.g. multiply by 3 becomes 3 1000 m*/   divide by 2 is  1000 2 m*/
2024-06-18 10:21:48 <veltas      > Or just */ if you're not using doubles, and then you can write 1.000 as the 'unit' which is a bit clearer
2024-06-18 10:22:17 <veltas      > And if I'm doing a big calculation with a given fixed point I might just define * and / to suit the units
2024-06-18 10:22:43 <veltas      > Or have maybe F* F/ (for 'fixed' ... pretending floating point doesn't exist!)
2024-06-18 10:23:20 <veltas      > I think you can definitely make fixed point hard for yourself, and trying to be as precise as possible will do that
2024-06-18 10:23:55 <veltas      > We need to remember 99% of problems on the planet can be solved more-precisely-than-necessary with like 5 decimal places
2024-06-18 10:36:55 <dave0       > veltas: we know pi to trillions of places, but 62 decimal digits can give you the circumference of the universe to planck length
2024-06-18 11:08:19 <veltas      > Also I'd sooner add vector floating point operations support to a Forth before 'just floats'
2024-06-18 11:09:05 <veltas      > If I care about doing that kind of work then I want the full horsepower of the machine, I've got no interest doing this in some rubbish legacy float stack
2024-06-18 12:18:50 <KipIngram   > Agree re: taking advantage of the vector operation support.  I also wish there was a really  nice way to program the GPU - that seems to be where the real power lies.
2024-06-18 12:31:28 <veltas      > nvidia have got open specs for their cards I think (?)
2024-06-18 12:31:31 <veltas      > Probably not easy
2024-06-18 12:31:46 <veltas      > The portable option is that vulcan bytecode format, if that's actually a thing now
2024-06-18 12:32:06 <GeDaMo      > https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation
2024-06-18 12:32:08 <veltas      > You'd be amazed how powerful the CPU's vector stuff is though
2024-06-18 12:38:40 <veltas      > https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#maxwell-and-pascal-instruction-set
2024-06-18 12:41:42 <vms14       > i didn't know i can use gforth for simple scripts by using the word BYE as it does not print any banner or additional stuff
2024-06-18 12:42:25 <vms14       > making simple scripts is a fun way to learn any language
2024-06-18 12:43:15 <vms14       > i've decided to learn forth properly and try to get used to it so i can make a better toy lang once i get comfortable with forth
2024-06-18 12:43:17 <GeDaMo      > I feel like I've seen something about using WASM on GPUs
2024-06-18 12:43:40 <vms14       > you mean waforth?
2024-06-18 12:44:22 <GeDaMo      > I hadn't heard of waforth :P
2024-06-18 12:44:22 <veltas      > We're having a conversation about low-level / forth GPU programming
2024-06-18 12:44:27 <vms14       > ah
2024-06-18 12:44:29 <vms14       > https://github.com/remko/waforth
2024-06-18 12:44:38 <vms14       > it's a forth written in web assembly
2024-06-18 12:45:33 <veltas      > SPIR is probably the best starting point for this
2024-06-18 12:51:10 <KipIngram   > Yes, I've got looking into that vulcan bytecode on my "list of things to get around to."
2024-06-18 12:51:28 <KipIngram   > Yeah, the CPU vector stuff looks pretty nice.
2024-06-18 15:07:25 <lf94-       > I learned about "local variables" in Forth yesterday via Reddit comments. Is it true you can really do : word { a b -- } ( use a or b now ?? ) ;
2024-06-18 15:07:45 <lf94-       > If so, why is this bad? Could someone really go into detail?
2024-06-18 15:12:30 <vms14       > in tile forth you can
2024-06-18 15:12:51 <vms14       > i liked that feature, but forthwrights might dislike it
2024-06-18 15:13:38 <vms14       > if you learn forth you are forbidden to use variables because you need to learn how to manage the stack properly first
2024-06-18 15:14:13 <vms14       > that is while you are learning, is better to not use variables and get used to the stack
2024-06-18 15:14:29 <vms14       > once you learn you can do whatever you want
2024-06-18 15:15:11 <lf94-       > ah
2024-06-18 15:15:59 <lf94-       > I just find it's kind of like creating temporary stack-based words
2024-06-18 15:16:19 <vms14       > https://github.com/cstrotm/tile-forth
2024-06-18 15:16:50 <vms14       > : 2drop { a b } ; 	: 2swap { a b c d } c d a b ;
2024-06-18 15:17:45 <lf94-       > Isn't that really nice
2024-06-18 15:17:46 <vms14       > i think any newcomer will like this feature, but it's not how forth is meant to be used
2024-06-18 15:18:05 <vms14       > it's nice because is what you are used to do and you don't want to be messing with the stack
2024-06-18 15:18:26 <lf94-       > I would have to >r r> swap to achieve the same
2024-06-18 15:18:27 <vms14       > but a forthwright needs the stack be a second nature
2024-06-18 15:18:55 <vms14       > the stack and the dictionary is what you have to understand how to use properly
2024-06-18 15:19:31 <vms14       > using temp variables allow you to program without knowing how to use the stack properly, which might be the reason is so discouraged
2024-06-18 15:19:44 <lf94-       > yeah.
2024-06-18 15:20:02 <lf94-       > Just like, for that example at least, it's a lot of stack swapping with return stack
2024-06-18 15:20:10 <vms14       > once you get comfortable with forth and learn how to think the forth way, then you can do whatever you want because you won't be abusing variables
2024-06-18 15:20:12 <lf94-       > >r swap >r swap r> swap r> swap or something
2024-06-18 15:20:33 <vms14       > with the time you will find a way to avoid those r> swap
2024-06-18 15:20:40 <vms14       > but never if you use variables
2024-06-18 15:20:44 <veltas      > It's probably because it's a feature you *can* define in most Forths, but it changes the language so much it doesn't *feel* like Forth anymore
2024-06-18 15:21:21 <veltas      > If you use it then you're almost using untyped reverse-polish C
2024-06-18 15:21:38 <vms14       > it limits you, because variables are important in most other languages, but here you have a stack and you can use it efficiently
2024-06-18 15:21:45 <veltas      > Manipulating the stack is hard and annoying, but it's a really interesting restriction that defines Forth
2024-06-18 15:22:04 <veltas      > Without it it's not really 'Forth' anymore.  I mean it is... but it's just not what 99% of Forth code looks like
2024-06-18 15:22:19 <veltas      > Relationship: it's complicated
2024-06-18 15:22:27 <vms14       > xD
2024-06-18 15:22:49 <vms14       > it's just not the way forth is meant to be used
2024-06-18 15:23:15 <vms14       > and to use a language properly you have to shift your mind into that way of the language
2024-06-18 15:24:13 <vms14       > if you fail to adapt to the language you have to find another language that suits you more
2024-06-18 15:24:28 <veltas      > To be fair a lot of e.g. gforth uses vars
2024-06-18 15:24:33 <veltas      > And they're easier to optimise than the stack
2024-06-18 15:24:43 <veltas      > I've seen very good code output for locals
2024-06-18 15:24:57 <veltas      > local vars I mena
2024-06-18 15:31:20 <crc         > I don't have local variables, but do have a word for restructuring the stack (e.g., I could define 2swap as `:2swap 'abcd 'cdab reorder ;`)
2024-06-18 15:51:08 <vms14       > i do have temp variables like the ones in tile forth, but this is because i try to avoid using the stack how its meant to be used
2024-06-18 15:52:44 <vms14       > and i suspect this affects indirectly to factoring
2024-06-18 15:53:22 <vms14       > because you can take more arguments for every word, while you are supposed to manage the stack properly by making more definitions that handle less arguments
2024-06-18 15:53:58 <veltas      > I have avoided it, but technically on most old forths you can access the first 5 return stack items at I I' J J' and K
2024-06-18 15:54:03 <vms14       > factoring is what helps you to manage the stack
2024-06-18 15:54:12 <veltas      > And on new forths too if they're smart about how LEAVE is implemented
2024-06-18 15:54:28 <veltas      > So you could use those a bit like registers
2024-06-18 15:55:35 <veltas      > And also on many forths I I' and sometimes J J' are actually registers (saved in return stack, but not stored in return stack)
2024-06-18 15:56:16 <crc         > 
ACTION has I J and K, but they access loop indexes not the return stack

2024-06-18 15:57:33 <lf94-       > vms14: how would you avoid those r> swap
2024-06-18 15:57:36 <lf94-       > in that case
2024-06-18 15:57:40 <lf94-       > you make it sound like there's a secret im missing
2024-06-18 15:58:10 <vms14       > no
2024-06-18 15:58:14 <vms14       > i have no idea
2024-06-18 15:58:20 <lf94-       > so please dont say that :)
2024-06-18 15:58:22 <vms14       > i mean, with the time you will find a way
2024-06-18 15:58:28 <lf94-       > there is no way.
2024-06-18 15:58:36 <veltas      > Depends on the problem
2024-06-18 15:58:44 <lf94-       > we're talking about 2swap
2024-06-18 15:59:01 <veltas      > How to implement 2SWAP ?
2024-06-18 15:59:08 <lf94-       > yes
2024-06-18 15:59:37 <vms14       > might not make sense to find another way in this case
2024-06-18 15:59:41 <lf94-       > crc defining 2swap like that is so nice.
2024-06-18 15:59:47 <lf94-       > vms14: thank you.
2024-06-18 16:00:25 <lf94-       > crc: it seems variables for _swapping_ is a really nice thing, and a lot of the time, you are swapping in like 50% of cases
2024-06-18 16:00:33 <vms14       > but if there was a better option, you would never find it if you use variables instead
2024-06-18 16:00:36 <lf94-       > and it's _SO_ easy to fuck up a swap
2024-06-18 16:00:43 <lf94-       > dup, over, etc, are not hard to mess up
2024-06-18 16:00:49 <lf94-       > but swap? yea, it fucks with your head
2024-06-18 16:01:17 <dave0       > my 2swap uses roll
2024-06-18 16:01:26 <lf94-       > oi, and how do you implement roll
2024-06-18 16:01:29 <dave0       > : 2swap   3 roll 3 roll ;
2024-06-18 16:01:40 <dave0       > i made it a primitive
2024-06-18 16:02:13 <veltas      > https://github.com/Veltas/zenv/blob/master/src/stack.asm#L27
2024-06-18 16:02:37 <dave0       > ooh Z80 assembly
2024-06-18 16:02:51 <lf94-       > ah roll is like rot on steriods
2024-06-18 16:02:54 <lf94-       > maybe I should use roll more
2024-06-18 16:03:17 <veltas      > PICK/ROLL are the standard words for far stack operations
2024-06-18 16:03:24 <lf94-       > i heard pick is bad
2024-06-18 16:03:27 <veltas      > PICK tends to be fast, ROLL can be very slow
2024-06-18 16:03:27 <lf94-       > practice
2024-06-18 16:03:35 <veltas      > Both are 'bad practice'
2024-06-18 16:03:44 <lf94-       > wow really
2024-06-18 16:03:49 <lf94-       > so what would good practice alt. be
2024-06-18 16:03:59 <veltas      > I don't think they're that bad
2024-06-18 16:04:07 <lf94-       > i mean to those saying it's bad
2024-06-18 16:04:10 <lf94-       > what are they suggesting
2024-06-18 16:04:11 <veltas      > Well ROLL is :P dave0
2024-06-18 16:04:34 <dave0       > if it's hard to juggle the stack, you could use variables
2024-06-18 16:04:53 <dave0       > temp1 2! temp2 2! temp1 2@ temp2 2@
2024-06-18 16:04:53 <veltas      > The classic solution is variables, temporary space like PAD etc
2024-06-18 16:04:59 <veltas      > ALLOT
2024-06-18 16:05:57 <veltas      > dave0: For primatives I prefer SP@ RP@ et al
2024-06-18 16:06:03 <veltas      > primitives*
2024-06-18 16:10:22 <dave0       > oh right.. i dont expose the stack pointers
2024-06-18 16:10:45 <veltas      > Well because I only write forths for normal machines so the 'stacks' are just normal memory
2024-06-18 16:11:00 <veltas      > PICK/ROLL make good primitives for VM's I think
2024-06-18 16:26:07 <lf94-       > you can explicitly specify stack item?
2024-06-18 16:26:10 <lf94-       > id love that
2024-06-18 16:36:18 <KipIngram   > lf94: Yeah, it is easy to mess up stack noodling.
2024-06-18 16:36:59 <KipIngram   > PICK isn't the really bad one - ROLL is the one that's terrible, because everything all the way down to the target item has to move.  PICK really isn't a lot worse than OVER (which is basically 1 PICK).
2024-06-18 16:37:06 <KipIngram   > DUP is basically 0 PICK.
2024-06-18 16:37:28 <KipIngram   > I added a facility to my Forth to let me index into the stack.
2024-06-18 16:37:53 <KipIngram   > I initially used the stack pointer as the index origin, but that was confusing because every time it changes everything gets "re-indexed."
2024-06-18 16:38:04 <KipIngram   > What I do these days is add a "frame pointer," and I index off of that.
2024-06-18 16:38:31 <KipIngram   > I use { and } to open and close "frames."  And inside I can index off of FP and everything stays the same throughout the frame.
2024-06-18 16:38:52 <KipIngram   > I could have written a general word for that, but I hardcoded a small group of primitives for the various items.
2024-06-18 16:38:58 <KipIngram   > f0, f1, f2, etc.
2024-06-18 16:39:04 <KipIngram   > Up through f6.
2024-06-18 16:39:16 <KipIngram   > It just kind of annihilates stack noodling.
2024-06-18 16:39:41 <KipIngram   > I try not to over-use it, but in a handful of cases it's really quite nice.
2024-06-18 16:40:44 <KipIngram   > They can be nested - { saves the current FP on the return stack and sets FP to SP.  } recovers the old FP, and also has the effect of resetting SP as well, so it makes stack cleanup "automatic" in a lot of cases.
2024-06-18 16:41:06 <KipIngram   > Even if I'm uncertain, because of how I wrote my code, of how much stuff needs to be discarded from the stack.
2024-06-18 16:41:22 <KipIngram   > And THAT was an unexpected fringe benefit - I didn't really plan that in advance.
2024-06-18 16:42:34 <dlowe       > the natural end point is the complete duplication of the C ABI :D
2024-06-18 16:43:14 <lf94-       > ah, sp@ and rp@ are not common it seems
2024-06-18 16:43:40 <veltas      > They're very common actually, although they might have different names in different places
2024-06-18 16:43:52 <lf94-       > dlowe it's just "swapping" is a legimitate massive source of errors.
2024-06-18 16:44:03 <lf94-       > vs dup or over which don't rearrange the stack
2024-06-18 16:44:13 <lf94-       > they just augment it, which makes it way easier to mentally hold onto
2024-06-18 16:44:36 <lf94-       > doing explicit stack access vs rot, roll, swap, is way easier on the human brain, and maybe even the computer brain.
2024-06-18 16:45:20 <veltas      > If you keep the amount of stuff on stack small it hurts less
2024-06-18 16:45:38 <veltas      > Just use variables, allot, etc for more room
2024-06-18 16:45:45 <veltas      > Or use locals etc if you want
2024-06-18 16:46:14 <veltas      > Do whatever you want, I used locals for a while and 'grew out of it', didn't do any permanent damage I don't think
2024-06-18 16:46:34 <GeDaMo      > Ideally, you wouldn't have a lot of values on the stack, they would be in arrays or structs in memory
2024-06-18 16:49:02 <vms14       > i think in forth any "bad practice" warning is just trying to encourage to learn forth properly and once you have learned those warnings do not longer apply because you have mastered the way forth does things
2024-06-18 16:49:32 <vms14       > so you use them if you think it's the right option
2024-06-18 16:49:44 <zelgomer    > agree. it occurred to me at some point that my problem with forth (maybe others', as well) was thinking of forth's stack like c's stack. this is wrong. instead, you should think of forth's stack as like you would think of registers if you were programming in c, and then the c version of a stack, when you move to forth, becomes some other memory region (variables, allotted regions named with create, etc.)
2024-06-18 16:52:18 <vms14       > for example to not use pick, because you will abuse it and prevents you from operating the stack properly
2024-06-18 16:53:13 <vms14       > you will always try to use forth the way other languages are used and it does not allow you to use it's potential
2024-06-18 16:54:09 <vms14       > if you have troubles with the stack you factor
2024-06-18 16:56:32 <veltas      > zelgomer: Agreed
2024-06-18 16:56:50 <veltas      > vms14: And agreed
2024-06-18 17:05:38 <lf94-       > I find myself most often dealing with ~3 stack items
2024-06-18 17:05:48 <lf94-       > As soon as you hit 4, shit becomes bad
2024-06-18 17:07:12 <vms14       > KipIngram what is the max of stack items allowed in your opinion?
2024-06-18 17:08:52 <vms14       > what did chuck establish as infinite stack
2024-06-18 17:08:56 <vms14       > i guess it was 16
2024-06-18 17:09:21 <vms14       > it's 18
2024-06-18 17:10:25 <vms14       > https://www.ultratechnology.com/1xforth.htm
2024-06-18 17:10:38 <vms14       > On the i21 we have an on-chip stack 18 deep. This size was chosen as a number effectively infinite.
2024-06-18 17:11:11 <veltas      > "3 stack items ought to be enough for anyone"
2024-06-18 17:11:35 <vms14       > even 3 can give enough trouble
2024-06-18 17:12:43 <veltas      > Those cheeky mixed/double arithmetic words can create a bit of friction
2024-06-18 17:20:17 <vms14       > veltas how much do you use the 2words like 2swap, 2drop, etc
2024-06-18 17:20:49 <veltas      > Quite a lot to be fair
2024-06-18 17:20:55 <vms14       > and which of those is the most used
2024-06-18 17:21:06 <veltas      > 2drop more often
2024-06-18 17:21:46 <veltas      > I'm using 2SWAP less over time
2024-06-18 17:22:00 <vms14       > because you tend to ignore results of words?
2024-06-18 17:22:23 <veltas      > I just often have multiple things to drop by end of a loop
2024-06-18 17:22:35 <veltas      > A lot of my loops end with 2DROP DROP or something
2024-06-18 17:23:02 <vms14       > how would you try to avoid that
2024-06-18 17:23:45 <vms14       > i assume most of the time is a hard thing
2024-06-18 17:24:51 <veltas      > You can't avoid it with a loop because you can't 'use up' the stack contents on the iteration step
2024-06-18 17:25:05 <veltas      > Unless you EXIT somewhere, using it up, in a conditional
2024-06-18 17:25:47 <vms14       > you can't cut the remaining execution you mean?
2024-06-18 17:25:52 <veltas      > I'm starting to use >R and R> more, which some people hate
2024-06-18 17:26:01 <veltas      > R@ is a bit like a 'register' for me
2024-06-18 17:26:14 <veltas      > And R> 2>R tucks something on return stack, so I'll probably use that more
2024-06-18 17:26:24 <veltas      > A bit gross maybe
2024-06-18 17:26:50 <veltas      > STASH or something might be better name
2024-06-18 17:27:04 <veltas      > Probably already widely used by forth code lol
2024-06-18 17:56:57 <KipIngram   > veltas: The F18A has an explicit "TOR" register cache alongside TOS.
2024-06-18 17:57:28 <KipIngram   > There's an instruction that swaps PC and TOR - I think that's how it does EXECUTE.
2024-06-18 17:57:57 <KipIngram   > I'm planning to do that on my next design; it's going to reflect a lot of F18A operation.
2024-06-18 18:41:52 <lf94-       > Anyone try that one Rockwell Forth SoC chip?
2024-06-18 19:38:25 <MrMobius    > 6511?
2024-06-18 19:38:39 <MrMobius    > or the modem chips that have a W register
2024-06-18 19:39:27 <MrMobius    > for hardware support of threaded code
2024-06-18 20:52:47 <veltas      > KipIngram: Shame, TOR's banned in lots of countries
2024-06-18 21:04:46 <lf94-       > MrMobius: 6511 I think
2024-06-18 21:05:35 <lf94-       > rockwell R65F11
2024-06-18 21:15:54 <KipIngram   > :-)
2024-06-18 21:51:10 <MrMobius    > lf94-: those pop up sometimes. there are some threads on the 6502 forum
2024-06-18 21:51:13 <MrMobius    > it's just a 6502 with a forth ROM afaik