2023-11-25 06:55:19 <olle        > Hm word of the day
2023-11-25 06:55:23 <olle        > But it's weekend.
2023-11-25 07:01:59 <user51      > true
2023-11-25 07:02:33 <olle        > My plans are destroyed due to ovulation.
2023-11-25 07:02:39 <olle        > I'm planless.
2023-11-25 07:02:43 <olle        > Except the sex part.
2023-11-25 09:46:57 <zelgomer    > gross
2023-11-25 10:26:46 <user51      > https://forth-standard.org/standard/core/FILL
2023-11-25 10:27:37 <user51      > Any reason why in ( c-addr u char -- ) char is TOS? ( char c-addr u -- ) seems more sensible to me
2023-11-25 10:27:49 <user51      > I'd guess backwards compatibility
2023-11-25 10:51:09 <zelgomer    > a lot of those are the way they are for composability/partial application
2023-11-25 10:51:50 <zelgomer    > i imagine the more common case is you'd have a word that fills some given range with a fixed value
2023-11-25 10:52:24 <zelgomer    > e.g., : wipe 0 fill ;  versus  : wipe 0 -rot fill ;
2023-11-25 11:19:38 <KipIngram   > ^ that seems right to me.  On could have argued that char addr count fill would be more in parallel with char addr c! etc.  But I think putting char last probably simplifies a few derivative words.
2023-11-25 11:21:29 <KipIngram   > <char> fill seems like an 'action specification'.
2023-11-25 11:21:55 <KipIngram   > It's what you're "doing to" <addr> <range>
2023-11-25 11:47:13 <user51      > Thanks!
2023-11-25 12:33:59 <KipIngram   > Probably keeping a general pattern of <object> <verb> in mind would lead you a good direction.
2023-11-25 12:34:33 <KipIngram   > I suppose that makes <char> and adverb?
2023-11-25 12:34:38 <KipIngram   > s/and/an/
2023-11-25 14:05:57 <KipIngram   > I think some new folks are here since t his was last linked:
2023-11-25 14:05:59 <KipIngram   > https://www.youtube.com/watch?v=0PclgBd6_Zs
2023-11-25 14:06:14 <KipIngram   > Chuck talking about the GA144.
2023-11-25 14:07:47 <KipIngram   > Particularly about the energy consumption of the chip, which is one of it's strongest aspects.
2023-11-25 14:21:58 <Zarutian_iPad> I an still on the opinion FlowBasedProgramming is the only sane way to program that chip
2023-11-25 14:25:02 <KipIngram   > Yeah, it does require you to flow your data across the chip as it's processed in different ways.
2023-11-25 14:25:54 <KipIngram   > I see it as strongly similar to digital circuit design.  The cores are so small that you can't think of any one of them doing any complex process all on its own.  It applies some "small transformation" to the data as it flows through and passes it on to other sections of the chip.
2023-11-25 14:26:03 <KipIngram   > That's exactly how signals flow around in a circuit.
2023-11-25 14:26:25 <KipIngram   > And just like a circuit, you can have several data flows all going on at the same time, raising the possibility of race conditions and so on.
2023-11-25 14:27:05 <KipIngram   > I think flow based programming (which I learned about from you, I think) is the best model for the way  modern processors work (even much larger ones).
2023-11-25 14:27:23 <KipIngram   > It naturally keeps you clear of cache collision issues.
2023-11-25 14:27:41 <KipIngram   > Since you can arrange for only one core to be "working on" a given piece of the data at a given time.
2023-11-25 14:28:23 <KipIngram   > Back in the early days of parallel programming they talked a lot about much more fine-grain parallelism, shere several processing elements might be collaborating on individual expressions.  But that kind of parallelism directly DOES encourage a lot of cache confict.
2023-11-25 14:28:31 <KipIngram   > conflict
2023-11-25 14:29:17 <KipIngram   > I still see the etherforth development system as the best example of using a GA144 I've seen so far.
2023-11-25 14:31:44 <KipIngram   > GA144 is kind of "part way down the road toward bitgrid."
2023-11-25 14:32:35 <KipIngram   > Bitgrid takes the "distributed flow-based processing" all the way to it's ultimate limit.
2023-11-25 14:32:43 <KipIngram   > its
2023-11-25 14:40:56 <KipIngram   > The ability to "execute" those comm ports - that was an inspired idea.
2023-11-25 14:44:37 <KipIngram   > I can't help thinking that digital signal processing applications were heavily on Chuck's mind when he designed this thing.
2023-11-25 14:46:11 <KipIngram   > And also that selling into military systems was something they hoped for.   And who knows - for all we know they have.  I suppose the military doesn't go around advertising what parts they use for things.
2023-11-25 14:57:10 <KipIngram   > I love how he actually implements is clock chip driver in *software*.  Actually manages the voltage applied to the crystal that way.  :-)
2023-11-25 14:59:04 <KipIngram   > I somehow had missed that bit previously - just finding out about it today.
2023-11-25 15:05:19 <MrMobius    > I'm still wondering what the performance is of this compared to an 8 bit MCU or arm
2023-11-25 15:05:40 <MrMobius    > I know the parallelism means they're not directly comparable but still curious
2023-11-25 15:13:43 <KipIngram   > I think the GA144 likely wins on power by virtue of being wholly asynchronous.
2023-11-25 15:14:16 <KipIngram   > In a standard microprocessor, at the very least you are driving the clock distribution network all the time, and those can be kind of hoggy.
2023-11-25 15:14:38 <KipIngram   > Since they're connected to practically every flip flop on the chip.
2023-11-25 15:14:57 <KipIngram   > Whether a flip flop is actually changing or not, its clock input still has a capcitance you are charging and discharging.
2023-11-25 15:40:13 <KipIngram   > This is interesting:
2023-11-25 15:40:18 <KipIngram   > https://www.youtube.com/watch?v=NcUJnmBqHTY
2023-11-25 15:55:06 <KipIngram   > That's neat - I may have to go check out his YouTube and see some live examples.
2023-11-25 16:12:06 <KipIngram   > https://www.youtube.com/watch?v=r-TLSBdHe1A
2023-11-25 16:17:34 <KipIngram   > Oh, neat.  ^ that one is on performance analysis; he mentions a tool called stabilizer, that repetitively runs your application under randomized variants of all the things that can "sneakily" change performance.  So you can know with more certainty whether changes you make "really" improve or degrade performance.
2023-11-25 16:17:43 <KipIngram   > That seems like a handy tool.
2023-11-25 16:25:15 <zelgomer    > f me... i have to get into intereting forth soon. i keep changing the forth "source" in comments, and then forget to change the actual assembler macros to match, and then scratch my head as to why it still doesn't work
2023-11-25 16:28:01 <KipIngram   > I hate it when I do that.  :-(
2023-11-25 16:28:19 <KipIngram   > I feel so so smart when I finally see where I just wasted two hours.
2023-11-25 16:28:56 <KipIngram   > I may be glad to have finally found the problem, but it's hard to feel very good about it as an "accomplishment" when I more or less did it to myself in the first place.
2023-11-25 16:29:32 <KipIngram   > that last video I linked above is very good.
2023-11-25 18:49:34 <KipIngram   > https://www.youtube.com/watch?v=1cRFfYQYGxE&list=RDCMUC_QIfHvN9auy2CoOdSfMWDw&index=17
2023-11-25 18:49:56 <KipIngram   > ^ a plug for using geometric algebra as our standard notiation, in math and in programming.
2023-11-25 23:43:39 <KipIngram   > Hah.  The Amiga 500 had a Motorola 68000 CPU and three coprocessor chips for video, audio, and "data manipulation."  Those coprocessors were code-named Denise, Paula, and Agnus (alternate spelling of Agnes, per Wikipedia).  I... rather like the implication there.  :-)
2023-11-25 23:44:08 <KipIngram   > Sounds like a splendid arrangement.
2023-11-25 23:44:53 <KipIngram   > The 68000 only used even numbered bus cycles to access RAM, so the plan was for the three ladies to use odd cycles.  But it turns out Agnus in particular was kind of greedy.
2023-11-25 23:45:33 <KipIngram   > During some DMA operations she'd starve the 68k completely out, apparently.