2023-07-13 04:39:37 <veltas      > KipIngram: 'threading' maybe?
2023-07-13 06:21:04 <KipIngram   > That's a good verb.  I'm referring to the noun for the entity that does the threading.
2023-07-13 06:21:15 <KipIngram   > Rotates among multiple threads.
2023-07-13 06:21:51 <KipIngram   > Hardware wise it's the core.  I'm pretty good with fiber, just because of the continuity it reperesents for me re: work.
2023-07-13 08:04:40 <KipIngram   > You know, I'd always assumed that in order to do multi-threading I'd need to modify my keyboard interface to be non-blocking, so that I could run other threrads while waiting for keystrokes.
2023-07-13 08:04:57 <Zarutian_iPad> KEY?
2023-07-13 08:05:43 <KipIngram   > But it occurs to me that's only if I want to restrict myself to one execution stream.  If I just used pthreads to launch a "keyboard  handler" thread, then it could still run blocking - it would just sleep while waiting, and meanwhile my other work would be done with a separate thread.  Or separate "fiber" in this new language.
2023-07-13 08:06:05 <KipIngram   > So I really only need non-blocking keyboard if I want a single fiber system to do multi-threading.
2023-07-13 08:06:15 <Zarutian_iPad> KEY?
2023-07-13 08:06:16 <KipIngram   > Yes, I think either KEY? or ?KEY.
2023-07-13 08:06:32 <Zarutian_iPad> 
ACTION gets a cracker.

2023-07-13 08:06:35 <KipIngram   > But the way I run the keyboard now such a word isn't possible.
2023-07-13 08:06:43 <KipIngram   > I run it blocking.
2023-07-13 08:06:52 <KipIngram   > I don't have a way to check and see if anything is pending.
2023-07-13 08:07:29 <KipIngram   > But I am tinkering quite a lot with the termios, so a further tinker to switch it to non-blocking would be trivial.
2023-07-13 08:08:05 <KipIngram   > veltas once recommended first making everything work single-fiber, and I do think that's a good idea.
2023-07-13 08:08:41 <KipIngram   > The way I'm planning to implement threading, all  primitives will be atomic operations.
2023-07-13 08:08:44 <KipIngram   > That's useful.
2023-07-13 08:08:55 <KipIngram   > For that matter, all SEQUENCEs of primitives will be atomic.
2023-07-13 08:09:10 <KipIngram   > The thread switching will happen in docol, while nesting down to a contained : def.
2023-07-13 08:09:51 <Zarutian_iPad> you going to do multithreading by doing threadswitch on an interval timer?
2023-07-13 08:10:08 <KipIngram   > But once I add a second fiber, atomic execution will no longer guarantee that nothing funky can happen.
2023-07-13 08:10:18 <Zarutian_iPad> sorry been deep in mcu programming lately
2023-07-13 08:10:24 <KipIngram   > I'm going to have a register down-counter.
2023-07-13 08:10:37 <KipIngram   > Each docol will decrement it, and when it hits zero I'll have a possible thread switch.
2023-07-13 08:10:49 <KipIngram   > so, that's "sort of" a timer, but not a "time-based" one.
2023-07-13 08:11:15 <KipIngram   > docol saves the current IP and re-loads it for the new : def.
2023-07-13 08:11:32 <KipIngram   > after I do that, I'll decrement the counter, and if it's non-zero just carry on and execute that new : def.
2023-07-13 08:12:00 <KipIngram   > If it's zero, though, I will reload the tick counter and pass through docol a second time, with rax loaded with the XT of the thread switch routine.
2023-07-13 08:12:20 <KipIngram   > It's very clean - that will just save the new : def IP on the stack and replace the call with one to the thread code.
2023-07-13 08:13:19 <KipIngram   > Basically four machine instructions implements the whole thing, with only two of them in the "main path" (a register decrement and a jump not taken).
2023-07-13 08:14:03 <KipIngram   > Those two instructions are the whole "cost" of the feature - most of the time they'll be the only part of it that executes.
2023-07-13 08:15:19 <KipIngram   > Something along these lines:
2023-07-13 08:15:21 <KipIngram   > https://pastebin.com/jRQ0HV89
2023-07-13 08:16:22 <Zarutian_iPad> too damn many popups on that pastebin
2023-07-13 08:16:43 <KipIngram   > Oh, sorry.
2023-07-13 08:17:01 <Zarutian_iPad> paste2.org seems fine
2023-07-13 08:17:05 <KipIngram   > Well, people complain when I post stuff like that inline.  Not a lot, but I was just trying to be a good citizen.
2023-07-13 08:17:08 <KipIngram   > I'll try it.
2023-07-13 08:18:00 <KipIngram   > https://paste2.org/EsC1fkDO
2023-07-13 08:18:06 <KipIngram   > Ugh - it didn't get the tabs right.
2023-07-13 08:18:16 <KipIngram   > I probably failed to set something I needed to set.
2023-07-13 08:18:54 <KipIngram   > But, I'm all for using "smaller players" for such things, so thanks.
2023-07-13 08:30:18 <KipIngram   > I need to invent some sort of appropriate frameowrk for "devices" / "pipes."  For a common thread that wants to run KEY for example, that should just be reading an item from some stdin device number.
2023-07-13 08:31:10 <KipIngram   > There will be a device driver thread that actually reads the keyboard, but it will write that information to a pipe that's associated with the process that owns the console currently.
2023-07-13 08:31:25 <KipIngram   > So when that process reads that pipe and nothing is there, it will just block.
2023-07-13 08:31:35 <KipIngram   > Until the device driver provides a keystroke.
2023-07-13 08:31:45 <Zarutian_iPad> bbl
2023-07-13 08:31:59 <KipIngram   > And that use of "block" refers to "within my system" - the thread will get swapped.
2023-07-13 08:32:40 <KipIngram   > I think the usual Linux approach, with devices stdin, stdout, and stderr, and hte ability to open more "devices" for whatever purpose, seems fine.
2023-07-13 08:33:39 <KipIngram   > So console capability brings those three devices automatically, but I want to be able to have threads create as many more as they need and use them to wire threads together in arbitrary ways.
2023-07-13 08:34:32 <KipIngram   > : put  ( val dev# --) ... ;
2023-07-13 08:34:40 <KipIngram   > : get  ( val dev# --) ... ;
2023-07-13 08:44:58 <KipIngram   > Well, I just uploaded my system's source to the oracle box.  It builds, but it doesn't run.
2023-07-13 08:45:08 <KipIngram   > Probably will take a little digging to figure out where it's vomiting.
2023-07-13 08:45:43 <KipIngram   > The oracle box is Rocky 9 - my notebook is Fedora 36.
2023-07-13 08:47:32 <KipIngram   > It's not making it to the actual Forth; it's dying somewhere in the initialization assembly.
2023-07-13 08:50:53 <KipIngram   > Ah, fixed it.  I just needed to remove an explicit library from the ld line in the build script.
2023-07-13 08:52:08 <KipIngram   > And, I didn't need that library bit on my notebook either - it must have been a leftover from getting it to build on my old work Mac, and it just "happened to work" on Fedora.
2023-07-13 08:53:01 <KipIngram   > Great - that totally works.  Loads my blocks and runs my editor and so on.
2023-07-13 08:53:04 <KipIngram   > Success.
2023-07-13 08:57:09 <KipIngram   > Oh, I guess I don't need val in get - it should just be : get  ( dev# -- val) ... ;
2023-07-13 08:57:37 <KipIngram   > And I'm thinking <n> pipe <name> to create a pipe that can hold <n> items.
2023-07-13 08:58:43 <KipIngram   > : key  ( -- c) stdin get ;
2023-07-13 09:11:32 <KipIngram   > Oh yeah - can't build this on the raspberry pi.  Wrong processor.  :-)
2023-07-13 09:12:26 <KipIngram   > I knew that already but forgot for a couple of minutes.
2023-07-13 10:56:36 <KipIngram   > Cool:
2023-07-13 10:56:39 <KipIngram   > https://www.electronicdesign.com/technologies/embedded/article/21269061/electronic-design-massive-chipletbased-fpga-designed-to-make-more-chips?o_eid=2379F0905723A3W&rdx.ident[pull]=omeda|2379F0905723A3W&oly_enc_id=2379F0905723A3W
2023-07-13 10:56:48 <KipIngram   > That looks like a beast.
2023-07-13 10:59:32 <KipIngram   > Holy shit... that thing costs in the $40k-$70k range on Digikey.
2023-07-13 10:59:38 <KipIngram   > Quantity... ONE.
2023-07-13 10:59:51 <KipIngram   > No wonder it's a beast.
2023-07-13 10:59:56 <thrig       > hang on, I think I have that in my wallet
2023-07-13 11:01:46 <KipIngram   > You betcha...
2023-07-13 11:03:35 <KipIngram   > I was expecting it would be expensive, just reading about it, but... that still came as a surprise.
2023-07-13 11:03:44 <KipIngram   > Obviously it's a niche market.  :-)
2023-07-13 11:04:17 <KipIngram   > Looks to me like it's intended to be a programmable, generic hardware emulator.
2023-07-13 11:04:27 <KipIngram   > Which is a pretty damn cool idea.
2023-07-13 11:08:00 <KipIngram   > Oh, looks like GA144 isn't colorForth-based anymore.
2023-07-13 11:08:03 <KipIngram   > Section 1.1 here:
2023-07-13 11:08:05 <KipIngram   > https://www.greenarraychips.com/home/documents/greg/DB014-190520-EVB002.pdf
2023-07-13 11:08:09 <KipIngram   > polyForth now.
2023-07-13 11:10:52 <KipIngram   > I have a hunch that highly parallel, high speed digital signal processing applications  (like one might use for things like military radar and so on) were on Chuck's mine when he did the GA144.
2023-07-13 11:11:10 <KipIngram   > Lots of little "calculation kernels" networked together in the array.
2023-07-13 12:30:51 <KipIngram   > Chucks infatuation with 18-bit computer words always amused me.
2023-07-13 12:42:02 <KipIngram   > F18A (GA144 core) documentation:
2023-07-13 12:42:04 <KipIngram   > https://www.greenarraychips.com/home/documents/greg/DB001-221113-F18A.pdf
2023-07-13 12:58:41 <KipIngram   > The instruction set is documented on page 5 of that document.
2023-07-13 12:59:25 <KipIngram   > Normally I'd say that given the deep thought Chuck no doubt gave that it would probably be useful to just emulate it.  But... Chuck was designing in hardware, not software, and that's a fairly major difference.
2023-07-13 13:02:14 <KipIngram   > He does some "clever" things with bits of the program counter, like controlling extended arithmetic mode (supporting carry/borrow) - emulating that in software would be perfectly possible, but clumsy I think.
2023-07-13 13:11:39 <KipIngram   > Now that's interesting.  You get your GA144 with an arrayForth or polyForth system designed to compile for it.  If you want to write your own compiler or otherwise deal directly with machine code, you first use the opcode values given to build your instruction word, and then you xor that with 0x15555.  That's binary 0b10101010101010101.  That's interesting - I assume there's some sort of white noise injection
2023-07-13 13:11:41 <KipIngram   > going on there, to minimize having too many signals change in the same direction at the same time.
2023-07-13 13:11:49 <KipIngram   > Reduce the likelihood of power glitches.
2023-07-13 13:12:07 <KipIngram   > We scramble data moving through our storage control hardware for similar reasons.
2023-07-13 13:12:40 <KipIngram   > I used to know a guy who told me I ought to figure out how we scramble and test with custom data patterns deliberately intended to defeat it.
2023-07-13 13:12:51 <KipIngram   > He predicted it would expose all kinds of problems.
2023-07-13 13:13:10 <KipIngram   > That guy once did a data integrity testing startup, so I imagine he knew what he was talking about.
2023-07-13 13:16:51 <thrig       > fuzz checking
2023-07-13 13:31:34 <KipIngram   > Yeah, if you have all of the pins on a chip, for example, toggle from low to high, or high to low, at the same time, that creates a surge on the power pins.
2023-07-13 13:31:47 <KipIngram   > A bigger one than if pins are flipping randomly.
2023-07-13 13:32:19 <KipIngram   > If one flips up while another flips down, they tend to offset each other.
2023-07-13 13:32:30 <KipIngram   > You don't need to move charge in or out of the chip in the same way.
2023-07-13 13:33:04 <KipIngram   > It's an inductance thing - you get a current pulse - a dI/dt, and L*dI/dt is the voltage that induces.
2023-07-13 13:33:13 <KipIngram   > If it's big enough it can glitch other logic.
2023-07-13 13:34:25 <KipIngram   > Patterns like all 0's or all 1's occur with significant probability in host data, but the exact (more or less random) patterns that would be required to counter-act the white noise injection are much more rare - you'd mostly have to do that on purpose.
2023-07-13 13:35:22 <KipIngram   > It was a nice idea, but first of all my job is to measure performance, not test data integrity, and even if I did that and caused failures the most likely outcome would be that I'd be questioned until what I'd done was exposed and then they would say "this probably won't happen in the real world."
2023-07-13 13:35:32 <KipIngram   > It's very unlikely they'd act on it.