2023-11-10 03:26:10 <KipIngram   > Hey, question.  If I have a move instruction that moves either direction between a register and a RAM cell, and then I follow that with a second instruction that does the same thing with another register and an *immediately adjacent* RAM cell, I'd expect that second one to be very low cost for cache reasons, right?
2023-11-10 03:26:46 <KipIngram   > I mean, it's clear that's the case for reads, but I guess it would also hold for writes, wouldn't it?
2023-11-10 03:32:06 <KipIngram   > A couple things I'm considering for the new system involve saving more than just the return address on the return stack.  If I also save my partially shifted instruction cell, then I can return back to "within" a cell, rather than just to the start of the next cell.  So I won't just waste the rest of a cell every time I make a call.
2023-11-10 03:32:55 <KipIngram   > But of course, that's an extra store on every call and an extra fetch on every return.  But they're right next to one another, so most of the time they'll share a cache line.
2023-11-10 03:34:14 <KipIngram   > And the other thing I'm considering is implementing my "jump back to start of word" (the "me" words) by having that address in a register.  So every time I call a new word that would have to be saved and updated for the new word.
2023-11-10 03:34:29 <KipIngram   > So that's three items I'm considering putting on the return stack.
2023-11-10 03:35:06 <KipIngram   > But it will eliminate having to fetch a jump offset out of the code stream; those "me" jumps will just become jmp <reg>.
2023-11-10 03:35:53 <KipIngram   > And for a loop I repeat a large number of times, that savings might add up.  Although the jump offset, if it were there, would also get cached the first time around the loop.
2023-11-10 03:37:13 <KipIngram   > The neat thing about doing "me" words this way is that I can have an instruction that will, if I want to, "slide forward" the jump target.  So I'll be able to jump back to anywhere in a word I choose.
2023-11-10 03:37:36 <KipIngram   > With the "default' being the beginning of the word.
2023-11-10 04:54:33 <KipIngram   > I'm also planning to have a "family" of call instructions that are standard size opcodes, but with each having a different call offset hard coded.  All of thse features are oriented toward letting me call "nearby" helper words without having to discard residual parts of my cells.  As much as possible will just be "opcodes."
2023-11-10 04:55:20 <KipIngram   > When I started planning this I was thinking in terms of six-bit opcodes, but I'm now looking at seven, or possibly even eight (maybe) to make room for that "family."
2023-11-10 04:56:00 <KipIngram   > I'll have a call instruction that can take an offset as well (like the F18A) to call things too far away to reach via the short call ops.
2023-11-10 12:25:58 <olle        > How would I add configuration on the behaviour of a word? In OOP you'd do obj->setSettingX(y) etc
2023-11-10 12:26:40 <olle        > Are there records in Forth?
2023-11-10 12:26:57 <olle        > https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Arrays-and-Records-Tutorial.html hm
2023-11-10 12:27:09 <GeDaMo      > Not in the standard but there are various implementations
2023-11-10 12:27:43 <olle        > k
2023-11-10 15:03:19 <olle        > So anyway, a forth bot in this channel perhaps?
2023-11-10 15:05:34 <olle        > I have a server on vpsnet I don't use much
2023-11-10 15:05:49 <olle        > I trust you guys to execute random code
2023-11-10 15:13:18 <MrMobius    > olle: I have been working on a forthbot this past week :)
2023-11-10 15:13:28 <olle        > MrMobius: Hooray and huzzah!
2023-11-10 15:13:50 <MrMobius    > dunno to ask in this channel for permission to run it here
2023-11-10 15:17:44 <crc         > I'll allow a forth bot
2023-11-10 15:19:39 <crc         > nonlinear: your connection issues are becoming a problem.
2023-11-10 15:22:57 <olle        > crc: What's the procedure?
2023-11-10 15:23:01 <olle        > To add a bot
2023-11-10 15:23:36 <MrMobius    > crc, thanks. Ill show you when I have it finished
2023-11-10 15:23:49 <crc         > just let me know the nick and have it join the channel
2023-11-10 15:24:21 <olle        > Aha
2023-11-10 19:22:21 <olle        > Aaah to have a tutorial for >in
2023-11-10 19:22:32 <olle        > I do have the code example
2023-11-10 19:24:09 <GeDaMo      > >in is a variable containing an offset into the input buffer
2023-11-10 19:27:14 <olle        > GeDaMo: A reference doc <> tutorial ;)
2023-11-10 19:27:22 <olle        > I'll play around
2023-11-10 19:29:46 <GeDaMo      > What are you trying to do with >in ?
2023-11-10 19:33:00 <KipIngram   > Some quite fun games can be played with >in.  ;-)
2023-11-10 19:33:12 <KipIngram   > Do it right and you can loop in the interpreter.
2023-11-10 19:33:45 <olle        > GeDaMo: Just understand it
2023-11-10 19:33:57 <olle        > Have to leave soon tho
2023-11-10 19:35:24 <GeDaMo      > In the code I wrote for you, I fetch >in to the stack  and later restore it so I can parse the name twice without having to copy it somewhere else first
2023-11-10 19:35:25 <olle        > Why is >in @ === 1?
2023-11-10 19:35:48 <olle        > Hm
2023-11-10 19:36:22 <GeDaMo      > It's an offset to some base value, maybe there's a space at the beginning?
2023-11-10 19:36:42 <olle        > No idea :)
2023-11-10 19:36:53 <olle        > Just using gforth prompt
2023-11-10 19:38:10 <GeDaMo      > If I do >in @ . I get 6
2023-11-10 19:46:34 <KipIngram   > At the time the @ executes, you have already parsed >in @_ where _ represents the space following @.
2023-11-10 19:46:39 <KipIngram   > That's 6 characters.
2023-11-10 19:46:44 <KipIngram   > Exactly what I'd expect.
2023-11-10 19:47:23 <KipIngram   > olle, did you do the @ alone on a line?
2023-11-10 19:47:30 <KipIngram   > Because that would make 1 make sense.
2023-11-10 19:52:26 <KipIngram   > At any rate, it's where the @ is on the line that should govern the value of >in that actually gets fetched.
2023-11-10 20:33:30 <gorenbk     > i don't get it... what are actual modern forth compilers?
2023-11-10 21:27:49 <KipIngram   > Can you be more specific?  What aspect of it are confusing you?
2023-11-10 21:35:23 <KipIngram   > s/aspect/aspects/
2023-11-10 22:17:05 <gordonjcp   > they left
2023-11-10 22:17:10 <gordonjcp   > I guess it was too confusing
2023-11-10 22:19:25 <thrig       > forth is the "Wizard's Bane"
2023-11-10 22:49:21 <veltas      > The join messages are mad today