2022-04-23 14:54:12 <KipIngram   > Well, I made it most of the way through that slide deck pretty well, then it "accelerated" at the end and I started to feel like I needed to at least know more about functional programming to follow.
2022-04-23 14:54:25 <KipIngram   > But - it was still a good resource for me; definitely bookmarked that one.
2022-04-23 14:54:51 <KipIngram   > I think I'm a lot more clear on "argument / function / operator" mechanics now.
2022-04-23 15:12:34 <nmz         > #forth is now #apl
2022-04-23 15:12:36 <nmz         > lmao
2022-04-23 15:22:48 <KipIngram   > Sorry man.  :-|
2022-04-23 15:23:07 <KipIngram   > I still love Forth more.  :-)
2022-04-23 15:24:28 <KipIngram   > It's like the old "He'll never leave his wife" cliche.
2022-04-23 15:47:26 <nmz         > we just need a forth chip
2022-04-23 15:47:37 <nmz         > to ease the performance penalties
2022-04-23 15:52:09 <KipIngram   > I agree.  I've noodeled around with some ideas for that over the years.  What I'd like to see is a separation of fetch and execute, so that fetch could be digging down through a call stack while execute was still working on instructions delivered earlier.  That gets right at the primary performance hit that highly factored Forth suffers.
2022-04-23 15:53:35 <KipIngram   > Some very casual measurements recently, using some instrumentation I've recently installed gave me the notion that I spend about 2/3 of my time in NEXT.  On the plus side, it means that "optimizing" my code with assembly in the deep nested loops has a lot of possible improvement to offer, but on the other hand it's too bad we have that inefficiency to start with.
2022-04-23 15:54:11 <KipIngram   > Primitives vary of course, in their "NEXT to non-NEXT" ratio - those measurements were just over the general operation of my interpreter.
2022-04-23 15:54:24 <KipIngram   > Averages over that operation, that is.
2022-04-23 15:55:13 <KipIngram   > Take a primitive like 1+ for example.  That's ONE instruction that works just on a register.  That's a very fast instruction.  The NEXT/non-NEXT ratio on that would be be blooming horrible.
2022-04-23 15:56:34 <KipIngram   > I'd guess that for the vast majority of my primitives NEXT is larger than the "non-NEXT" code.
2022-04-23 15:57:04 <KipIngram   > So anyway, paralleling that type of overhead with actual code execution would be a huge win.
2022-04-23 15:57:32 <KipIngram   > And it's pretty straightforward to do, so long as conditional branches aren't interfering.
2022-04-23 16:44:02 <KipIngram   > The design I scratched out was a 16-bit system, with each 16-bit cell specifying 15 address bits for a called word or three packed opcodes.  The 16th bit specified which.  So it looked pretty clear that fetch would be able to get ahead of execute on a run of opcodes, which would buy it time to unravel calls.  You could design fetch to handle conditional branches by fetching down both paths some distance
2022-04-23 16:44:04 <KipIngram   > before it paused - it would resume as soon as one of the paths was chosen.  How well that worked would really depend on how often conditional branches occur in typical code, which we could probably assess using exsting systems.
2022-04-23 16:46:19 <KipIngram   > I guess a trick for writing good code on such a system would be to try to avoid having multiple conditional branches too close together.
2022-04-23 16:46:47 <KipIngram   > Otherwise you'd be faced with trying to deal with more than one fork.
2022-04-23 16:47:25 <KipIngram   > And all of the typical "calculate, don't choose" advice re: Forth - that would pay off in such an architecture.
2022-04-23 17:11:20 <KipIngram   > Zarutian_HTC: Any further thoughts on the SIMD vm?
2022-04-23 17:16:53 <Zarutian_iPad> KipIngram: other than it is high time for it? no I think I covered it
2022-04-23 17:23:32 <Zarutian_iPad> I am tempted to write one implement in IBM 370 vector instructions
2022-04-23 17:30:24 <Zarutian_iPad> why? because I have been reading those manuals too much lately
2022-04-23 17:38:12 <KipIngram   > :-)  Yeah, it's been fun watching you slurping up 370 info.  Do you see reasons that it would be more feasible on a 370 that on the x86_64 SIMD architecture?
2022-04-23 17:40:04 <Zarutian_iPad> no reason, other than I detest x86
2022-04-23 18:05:58 <Zarutian_iPad> I think it could work with ARM Neon, PowerPC ActiveVect, and others
2022-04-23 18:06:51 <Zarutian_iPad> I have not looked at RISC-V SIMD but I suspect it would work there too
2022-04-23 18:42:27 <KipIngram   > :-)  Well x86 is what I know and what I have - but I understand.
2022-04-23 18:42:57 <KipIngram   > If I were going to tinker with it that's how I'd have to do it.
2022-04-23 19:24:33 <Zarutian_iPad> I think Hector, the IBM 370 emulator, has vector support ;)
2022-04-23 21:20:09 <KipIngram   > :-)