2022-07-23 08:05:03 <KipIngram   > Ok, I'd never thought of stashing the quotations in the return stack.  I'd always thought in terms of compiling them inline like everything else, with a jump over them for the mainline code.  Putting them on the return stack is a neat idea, because you can get rid of them.  In fact, you could put ANYTHING just about there.  Code, data, etc., and obviously the benefit is it's transient.
2022-07-23 08:06:16 <KipIngram   > Might make more sense to have a separate stack for that kind of thing; I'd have to think about it some.
2022-07-23 08:07:05 <KipIngram   > If it were on the return stack it seems like you'd have to have explicit stuff to drop it when it was time, so you got back to the right return addresses at the right time.
2022-07-23 08:09:05 <KipIngram   > Well, maybe you could do it that way.  You'd stash the material on the return stack, and then stash a return that took you to code that droped it.
2022-07-23 08:09:18 <KipIngram   > Then the drops would just be caused by returning out of the scope.
2022-07-23 08:12:31 <KipIngram   > But actually, wouldn't that duplicate things?   You have to have those things somewhere to put them on the return stack FROM, right?  Like it could be compiled in line like a ." string, only the action would be to copy it to the return stack?  And you could just use it in place instead of doing that.
2022-07-23 08:13:32 <KipIngram   > Unless you compiled it at execute time, and that would be slow.
2022-07-23 08:15:28 <KipIngram   > By the way, I think that's a little bit like how opencl for Forth would work - you'd store these "kernels" inline with your Forth code, and the action when you came to that would be to copy the kernel code over to the GPU.
2022-07-23 08:16:47 <KipIngram   > It looks like you can pre-compile it if you want to, but from what I could tell rerading yesterday opencl drivers have the ability to compile opencl c on the fly, so it could also be stored as an opencl c string.
2022-07-23 09:43:40 <KipIngram   > remexre: I assume you intend to compile these quotations at the usual compile time, right?  You wouldn't be processing the source code at runtime, would you?
2022-07-23 13:23:03 <remexre     > KipIngram: er yeah, I didn't mean to put the code itself on the r-stack, just the XTs
2022-07-23 14:01:34 <KipIngram   > Ah, I see.  Well, I hadn't thought of that either, but that might be a clever thing to do.
2022-07-23 14:35:17 <KipIngram   > That would let you choose at run-time which options to make available.
2022-07-23 15:14:43 <imode       > anybody have any resources on how the GA144 bootstraps.
2022-07-23 15:15:32 <imode       > by default with no program ROM I imagine each node needs to take some instructions from some input stream.
2022-07-23 15:17:59 <imode       > ah, yeah, that's how that works. "start executing from any neighboring node" on startup.
2022-07-23 17:02:04 <KipIngram   > The best docs I've seen for all that stuff is here:
2022-07-23 17:02:06 <KipIngram   > https://etherforth.org/
2022-07-23 17:02:44 <KipIngram   > It's not about the GA144 *per se*, but it doesn't run anywhere but on it, so it gets talked about a fair bit.
2022-07-23 17:03:39 <KipIngram   > I think every core comes up trying to "execute from any port."
2022-07-23 17:03:57 <KipIngram   > It's up to you to make sure stuff only shows up from one port on any given core there at the beginning.
2022-07-23 17:04:12 <KipIngram   > And also to percolate your content across the array.
2022-07-23 17:04:14 <imode       > yep. I went down a rabbit hole and now I have a one-wire encoding for instructions.
2022-07-23 17:04:48 <KipIngram   > I think it would be fun to play with, but I just haven't developed enough of an itch to dive in.
2022-07-23 17:04:53 <imode       > my lil' ring processor has eight instructions, two of which can control the execution of neighboring cores.
2022-07-23 17:05:00 <imode       > or rather, the neighboring _core_.
2022-07-23 17:05:39 <imode       > the idea being that the instruction stream for the whole core is a threaded mix of passing instructions along. communication is just executing instructions that control writes to local memory on the core.
2022-07-23 17:06:06 <KipIngram   > Yeah, makes sense.
2022-07-23 17:06:23 <KipIngram   > And since the GA144 cores are asynch, they just do that first read and sit there and wait for it to return something.
2022-07-23 17:06:31 <imode       > yep.
2022-07-23 17:07:15 <imode       > my protocol is essentially.. high signal, move to the next instruction in the instruction ring, low signal, execute the highlighted instruction in the instruction ring.
2022-07-23 17:07:37 <imode       > so if you're on instruction 0, and you wanna execute instruction 4, you need three high signals and a low signal.
2022-07-23 17:07:58 <imode       > or rather, execute instruction 3.
2022-07-23 17:09:59 <imode       > simplifies the underlying core design.
2022-07-23 17:10:50 <imode       > the concept of an ether message in etherforth is interesting.
2022-07-23 17:10:59 <imode       > all relative addressing.
2022-07-23 17:11:43 <KipIngram   > Chuck seems to have no shortage of clever ideas.
2022-07-23 17:16:43 <imode       > it makes sense if you're fixed in place along a larger structure, relative addressing means "hop here".
2022-07-23 17:18:44 <KipIngram   > Yes.
2022-07-23 17:53:14 <MrMobius    > imide, do you have a ga144 set up?
2022-07-23 17:55:57 <imode       > not yet. not sure if I want one. working on my own thing.
2022-07-23 18:00:11 <KipIngram   > How are you doing it?  FPGA of some kind?
2022-07-23 18:00:53 <KipIngram   > I've never tried anything "processor" that's that minimal.
2022-07-23 18:01:14 <KipIngram   > My Forth processor thinking was more conventional - larger memory space, deeper stacks, etc.
2022-07-23 18:13:31 <imode       > KipIngram: software simulation and eventual FPGA.
2022-07-23 18:13:42 <imode       > my entire design is based around rings of rings of rings of rings of asynchronous pipelines.
2022-07-23 18:14:31 <imode       > and since I'm probably going to be working on an FPGA, I wanna be able to fit as many of those things as possible on whatever design space I have.
2022-07-23 18:15:22 <imode       > which means design optimizations to favor large-scale, fine-grained parallel execution vs. small scale loose-grained parallel execution.
2022-07-23 18:15:46 <imode       > that means.. bit-serial, low data-bus-width machines.
2022-07-23 18:17:03 <imode       > and instead of working with a 2D plane, the top-level topology is a ring.
2022-07-23 18:17:18 <imode       > so you can use a space-filling curve to auto-plan the chip layout.
2022-07-23 18:35:56 <KipIngram   > Neat.
2022-07-23 18:36:13 <KipIngram   > I once wondered if a bit serial processor might be a win.
2022-07-23 18:36:19 <KipIngram   > You'd be able to have a ton of them.
2022-07-23 18:36:37 <KipIngram   > And it solves the carry ripple problem for adds, which generally is solved with "even more logic."
2022-07-23 18:37:03 <imode       > exactly.
2022-07-23 18:37:26 <KipIngram   > Verilog simulation, or a software simulation?
2022-07-23 18:37:50 <KipIngram   > You might find Verilator interesting.
2022-07-23 18:38:13 <imode       > software simulation, because it's a software/hardware model.
2022-07-23 18:38:21 <KipIngram   > It takes (even big) Verilog designs and creates C code that will do a cycle-accurate simulation of the design.
2022-07-23 18:38:27 <KipIngram   > Just makes an executable that runs the sim.
2022-07-23 18:38:31 <imode       > ahh yeah.
2022-07-23 18:38:57 <imode       > the benefit of async execution is that you don't exactly need cycle-accurate, just handshake-accurate.
2022-07-23 18:40:58 <KipIngram   > That's true.
2022-07-23 18:41:39 <KipIngram   > And clock distribution is a pain in the ass anyway.  They try to put stuff in FPGAs to help with that, but if you're designing silicon it demands attention.
2022-07-23 18:42:32 <imode       > exactly.
2022-07-23 19:03:40 <KipIngram   > How do you handle conditional branch type things?
2022-07-23 19:05:12 <imode       > there's a couple of ways you could handle 'em.
2022-07-23 19:06:35 <imode       > if each of the cores has no program memory, then you'll need to rely on communication to and from a central controller that can dispatch sequences of instructions followed by a conditional selector (either 0 or 1).
2022-07-23 19:14:55 <imode       > so if you have 4 elements in the ring, zero through three, and you want each of them to execute their own set of instructions, you need to have core 0 perform an instruction, then have it pass an instruction on to core 1. core 1 performs its instruction, and then you have core 0 tell core 1 to give core 2 an instruction. so on and so forth.
2022-07-23 19:15:22 <imode       > "do something, pass an instruction along. do something, pass an instruction along."
2022-07-23 19:19:43 <imode       > it's equivalent to one large "scan-line" that's broadcast across the chip.
2022-07-23 19:20:28 <imode       > core 0 does something, starts telling core 1 what to do. core 1 does something, core 0 starts telling core 1 to tell core 2 what to do.
2022-07-23 19:20:29 <imode       > etc. etc.
2022-07-23 20:07:26 <imode       > that's actually how the individual instruction units are hooked up as well. they make local choices and govern what the instruction unit next to them will do.
2022-07-23 20:37:19 <KipIngram   > Catching up - I had to cook dinner.  MIL came to join us, and I was tasked with making pizza.
2022-07-23 20:37:33 <imode       > oh that sounds like fun.
2022-07-23 20:38:12 <KipIngram   > So it's kind of globally pipelined?
2022-07-23 20:38:28 <imode       > kinda. the individual cores behave like that.
2022-07-23 20:38:54 <imode       > you have different functional units arranged in sequence, and they're all capable of signalling to eachother over that one wire protocol.
2022-07-23 20:39:05 <KipIngram   > Cool.
2022-07-23 20:39:22 <imode       > and then you have one functional unit, a process controller, that's got a buffer for holding messages.
2022-07-23 20:39:29 <imode       > which are far more well-formed.
2022-07-23 20:39:46 <imode       > and make it so you can send instructions through the pipeline and actually do the parallelism.
2022-07-23 20:39:57 <imode       > so, individual cores are sequential "pipelines" that tell eachother what to do.
2022-07-23 20:40:16 <imode       > whereas the whole chip network is a pipeline of those pipelines.
2022-07-23 20:40:22 <imode       > with buffers, supporting parallel processing.
2022-07-23 20:42:48 <thrig       > so, it's full of tubes?
2022-07-23 20:43:05 <imode       > yep.
2022-07-23 20:43:09 <imode       > tubes of tubes of tubes of tubes.
2022-07-23 20:53:08 <KipIngram   > Wait, is "tube" referring to some formal software concept here?
2022-07-23 20:53:53 <thrig       > if by formal you mean "some U.S. senator who made certain meme-worthy remarks about the Internet" then yes
2022-07-23 20:55:04 <thrig       > perhaps it was Ted Stevens
2022-07-23 20:56:25 <imode       > the internet is not a big truck.
2022-07-23 20:57:20 <thrig       > ... but the "tubes" actually works for SMTP among other things
2022-07-23 21:04:28 <KipIngram   > Ok.  So, no.  Not in the way that "ropes," which came up a few months ago, means a specific thing.
2022-07-23 21:05:43 <imode       > nah.
2022-07-23 21:05:44 <imode       > it's a joke.
2022-07-23 21:05:48 <imode       > the internet is a series of tubes.
2022-07-23 21:16:10 <imode       > the software simulator is written in Go currently, and it's actually the "basis" for the software stack's VM for now.