2022-06-24 05:21:11 <veltas      > KipIngram: Yeah I was working on a parser, it would work quite well parsing normally from what I can tell
2022-06-24 05:21:22 <veltas      > I've just not been working on it because I have more interesting stuff to do
2022-06-24 05:21:36 <veltas      > Recently been working on a Forthy visual text editor
2022-06-24 05:21:51 <veltas      > in ANS Forth
2022-06-24 05:23:19 <veltas      > JSON parser I mean
2022-06-24 05:47:59 <boru        > Neat idea, turning the JSON syntax into words.
2022-06-24 05:49:42 <boru        > It could become a bit like the shunting yard algorithm then, I think.
2022-06-24 06:10:27 <veltas      > Well I was going the route of not using the FORTH parsing
2022-06-24 06:11:04 <veltas      > I don't think that's a good idea personally, I mean a JSON parser should be able to parse JSON files, and how would you handle strings, etc
2022-06-24 06:11:30 <veltas      > You can define a new format but then I'd question why do any of this structured data stuff at all
2022-06-24 06:11:54 <boru        > I think that's all valid, I just thought it was a cool idea.
2022-06-24 06:13:10 <veltas      > One of the more interesting questions to me at the moment is generally how to express pattern matching in forth
2022-06-24 06:13:47 <boru        > Implementation seems open to fun ideas, but expressing it, yeah, seems less fun.
2022-06-24 06:14:25 <boru        > The most expressive RE interface I've come across (subjective, of course), is Perl's.
2022-06-24 06:15:11 <veltas      > I think the best way to do pattern matching in forth is to have words to help define the basic components of the pattern, and combining words that allow alternatives and repeats
2022-06-24 06:15:41 <veltas      > And then you pull it together in forth words, and backtracking implemented with exceptions
2022-06-24 06:15:59 <veltas      > That's how I was implementing the JSON parser in forth and it was working well
2022-06-24 06:16:08 <veltas      > I just got bored and did other things
2022-06-24 06:16:17 <boru        > I can relate to that.
2022-06-24 06:17:05 <boru        > Happens with a lot of projects. The initial enthusiasm of having a good idea, and then losing motivation to improve it, once proving it.
2022-06-24 06:17:33 <boru        > Or realising it was more work than you initially though, and moving on to something else, promising yourself you'll come back it.
2022-06-24 06:17:55 <veltas      > Here is my design anyway (this is an example of the interface I've designed, rather) https://pastebin.com/raw/aEKbTSuT
2022-06-24 06:19:02 <boru        > Hmm, seems clean enough.
2022-06-24 06:19:04 <veltas      > So for example, the last word example4 parses JSON objects where there is a key "id" with a field that is a string
2022-06-24 06:19:28 <veltas      > {{ parses a '{' token (discarding whitespace etc)
2022-06-24 06:19:59 <veltas      > And then json-process takes 3 things: Initial patterns to ignore, pattern to search for, and then further pattern to ignore
2022-06-24 06:21:09 <veltas      > For example the first ignore word contains  s:v ,,
2022-06-24 06:21:23 <veltas      > Which parses a string:value pair and a comma
2022-06-24 06:24:28 <veltas      > Basically if it ever fails to match something it throws a parsing exception, and that's caught by combining words where backtracking is appropriate
2022-06-24 06:24:53 <veltas      > And such backtracking words will call stuff with CATCH and also save the current parse position and restore it on parse exception
2022-06-24 06:55:25 <veltas      > boru: I'm quite bad, I start everything as if I'll finish it but never really finish anything
2022-06-24 06:55:46 <boru        > I think that describes most of us.
2022-06-24 06:55:48 <veltas      > My forth environment for the ZX Spectrum is one of the few things I've gotten to a releasable state and even then there's more I'd like to do to it
2022-06-24 06:56:07 <boru        > I have few software projects I will consider "finished".
2022-06-24 06:56:14 <veltas      > But at least it's out there and has been used by at least one other person lol
2022-06-24 06:57:17 <boru        > Personally, I don't consider that any sort of metric. Any of the programs I release into the public domain, I put there because I think they were good ideas that someone else might develop, or because I think they might be useful to someone else, future me included. Whether or not people use them, doesn't really bother me.
2022-06-24 06:57:51 <veltas      > I do stuff hoping people will use it, it makes me happy knowing they have
2022-06-24 06:58:17 <boru        > I'm not saying it's not rewarding when other people use it, just that I don't really find it important that they do.
2022-06-24 06:58:34 <veltas      > I hope people will use vi.fs too
2022-06-24 06:58:38 <boru        > I think the more important aspect is sharing ideas and knowledge.
2022-06-24 06:58:59 <boru        > Is it vi implemented in Forth?
2022-06-24 06:59:19 <veltas      > It's more like a visual version of the starting forth editor
2022-06-24 06:59:31 <veltas      > So it's like vi but with commands based on the starting forth block editor
2022-06-24 06:59:33 <boru        > Ah, I see.
2022-06-24 06:59:35 <veltas      > But it's meant for proper files
2022-06-24 07:00:25 <veltas      > I want to produce a proper manual and tutorial for it etc
2022-06-24 07:00:48 <veltas      > I think the most important goal is to be able to use it daily as my actual text editor
2022-06-24 07:01:14 <veltas      > If I can do that then I can honestly try and share it with people
2022-06-24 07:03:40 <veltas      > So it's going to have features like multiple buffers, auto-indent, different file ending formats, undo + history
2022-06-24 07:03:56 <veltas      > Stuff that I think is crucial for a productive text editor
2022-06-24 07:35:16 <veltas      > It's weird how current definitions of "functional programming" probably exclude lisp
2022-06-24 07:36:00 <veltas      > There's no abstract way of thinking about it that could differentiate lisp from forth either really
2022-06-24 07:37:27 <veltas      > I think really the question is just genealogy, some languages inherit more from lambda calculus and some more from turing machines
2022-06-24 07:40:31 <veltas      > And when you phrase it like that it's as obvious as it should be that Lisp is functional and Forth is procedural
2022-06-24 07:48:03 <KipIngram   > boru: I think it may have been MrMobius that suggested that pre-pass splitting the json into spaced words.  If that's wrong, my apologies to the originator - old man memory here.
2022-06-24 07:49:36 <KipIngram   > I had proposed a modification to the system that involved havinga definable class of characters that would always represent stand-alone tokens (that would no longer have to be spaced apart) - I liked it, but I also had to kind of admire the simplicity of avoiding that.
2022-06-24 07:52:04 <KipIngram   > And yes - good point about strings; one would have to think about how that would work if those characters needed to appear inside a string.  Might not be a problem - seems like you wouldn't be paying attention to what characters were "inside a string" anyway?
2022-06-24 07:52:23 <KipIngram   > When reading a string you'd only be looking for the string terminator.
2022-06-24 07:53:07 <KipIngram   > If you're going to have strings in Forth you need to be able to have spaces in them, so you have to deviate form the normal parsing for that anyway.
2022-06-24 07:53:15 <KipIngram   > s/form/from/
2022-06-24 07:54:52 <KipIngram   > I've agitated over how to do strings - I always wind up thinking the most "Forth true" way is to have some word, call it s, that works with something like this: s <arbitrary terminator><string chars><arbitrary terminator>
2022-06-24 07:55:14 <KipIngram   > That way you can pick any terminator you like case by case - you pick anything that you don't need in that string.
2022-06-24 07:55:30 <veltas      > 'recognizers' let you handle any string but it just makes it all more complicated
2022-06-24 07:55:35 <veltas      > Forth: keep it simple
2022-06-24 07:55:45 <KipIngram   > I do agree with that fundamentally.
2022-06-24 07:55:48 <veltas      > Simple and stupid, so forth programmers (like me) can handle it lol
2022-06-24 07:56:40 <veltas      > The truth is that forth's syntax actually makes a lot more sense to normal people than regular programming syntax
2022-06-24 07:57:10 <veltas      > Because regular programming syntax makes so many assumptions about spacing and precedence and stuff that we all forget we had to learn at some point
2022-06-24 07:57:20 <veltas      > But forth is just "give me a word"
2022-06-24 07:57:54 <KipIngram   > I just find that I get tempted from time to time that a string is really something like a number - it's a literal data item, and I start wanting to have it treated somehow more like number literals.
2022-06-24 07:58:05 <KipIngram   > Probably the wrong way to go, though.
2022-06-24 07:58:07 <veltas      > Yeah a few forths do this
2022-06-24 07:58:11 <veltas      > I agree it's the wrong way
2022-06-24 07:58:26 <KipIngram   > It's a decisive step away from "Forth."
2022-06-24 07:58:47 <veltas      > The only thing forths should support for numbers is separators, and conventionally the presence of separators indicates a double number
2022-06-24 07:59:17 <veltas      > And should support floating point numbers if you have floating point support (with mandatory E)
2022-06-24 07:59:18 <KipIngram   > Ever since I started doing 64-bit systems I kind of lost interest in doubles
2022-06-24 07:59:32 <KipIngram   > They seemed less necessary.
2022-06-24 07:59:36 <veltas      > Yeah they don't have a lot of charm in 64-bit
2022-06-24 07:59:39 <KipIngram   > I tend to let the . designate floats.
2022-06-24 07:59:52 <veltas      > But separators are awesome, I can write: 2022-06-24
2022-06-24 07:59:56 <veltas      > And that's a number
2022-06-24 08:00:01 <KipIngram   > That's true.
2022-06-24 08:00:23 <veltas      > Or you can mandate a local date format like 24/06/2022 if you hate americans
2022-06-24 08:00:28 <veltas      > or vice versa
2022-06-24 08:00:31 <KipIngram   > Although I never did one that way - when I did do doubles the separator had to be .
2022-06-24 08:00:59 <veltas      > Forth Inc forths allow -,.:/
2022-06-24 08:01:18 <veltas      > Of course - means negative at the front
2022-06-24 08:01:26 <veltas      > Elsewhere it's a separator
2022-06-24 08:02:02 <KipIngram   > Hmmm.  Well, I presume they've given that a fair amount of thought.
2022-06-24 08:02:16 <veltas      > It's one of the things that makes forth better looking than pretty much any other language
2022-06-24 08:02:39 <veltas      > What language lets you write 2022-06-24 and have it just mean something immediately without any special functions to handle that syntax
2022-06-24 08:03:16 <veltas      > And forth doesn't have a lot of 'pros' to its syntax, so I appreciate it
2022-06-24 08:03:55 <KipIngram   > Yeah - I'm sitting here appreciating it now.
2022-06-24 08:04:28 <KipIngram   > Usually when I think about some "modification" to the usual way of doing things, it's precisely for that reason: to make the written code look "cleaner."
2022-06-24 08:04:38 <KipIngram   > I have an appreciation for pretty code.
2022-06-24 08:07:07 <veltas      > I will say doubles make more sense in assembly
2022-06-24 08:07:30 <veltas      > Where e.g. x86 provides double results for multiplication, and does the reverse for division
2022-06-24 08:07:40 <veltas      > So suddenly M* and M/ make sense
2022-06-24 08:07:58 <veltas      > And then it's trivial to implement D+ etc
2022-06-24 08:07:59 <KipIngram   > Yes.
2022-06-24 08:08:08 <veltas      > with carry support which most archs have
2022-06-24 08:09:28 <KipIngram   > I just have a strong interest in scientific computing, and almost always want to have easy access to floats.  Of course, it's easy enough to have both - you could have . give doubles and use scientific notation with an e to get floats.
2022-06-24 08:09:41 <veltas      > Yeah
2022-06-24 08:09:58 <KipIngram   > Though that's complicated slightly by e/E also being a hex digit.  This last go round I used ^ instead.
2022-06-24 08:10:13 <KipIngram   > But have never felt quite right about how that looks.
2022-06-24 08:10:26 <KipIngram   > It's just what NUMBER "does" right now.
2022-06-24 08:10:41 <veltas      > I've been learning about kahan summation, dekker multiplication, and veltkamp splitting recently
2022-06-24 08:11:07 <veltas      > Essentially 'double numbers' for floats (although really they're more like quads since we already use 'double floating point')
2022-06-24 08:11:07 <KipIngram   > :-(  I know what none of those are.  I'll have to look them up; sounds like it might be interesting.
2022-06-24 08:11:25 <veltas      > It's really interesting
2022-06-24 08:11:42 <veltas      > And I've come up with a method of doing high accuracy division with it too
2022-06-24 08:11:43 <KipIngram   > I've never bothered with single precision floats - I just went straight for double
2022-06-24 08:12:01 <veltas      > On 32-bit x86 I remember floats were slower than doubles a lot of the time
2022-06-24 08:12:06 <veltas      > Or same performance
2022-06-24 08:12:07 <KipIngram   > It does give me the advantage of having EVERYTHING be 64-bit.
2022-06-24 08:12:38 <veltas      > I've dabbled in half precision floats too lol
2022-06-24 08:12:53 <KipIngram   > Oh - 16 bits?
2022-06-24 08:12:57 <veltas      > Popular in ML although that's not what I do
2022-06-24 08:13:11 <veltas      > It's also used for low resolution sensor chips
2022-06-24 08:13:24 <veltas      > Usually those used fixed point though
2022-06-24 08:15:01 <KipIngram   > Oh.  Kahan summation DOES look interesting.
2022-06-24 08:16:37 <veltas      > KipIngram: You might find https://indico.cern.ch/event/313684/contributions/1687773/attachments/600513/826490/FPArith-Part2.pdf interesting
2022-06-24 08:16:45 <veltas      > Slightly more digestible
2022-06-24 08:17:36 <veltas      > If you want the detail then read https://csclub.uwaterloo.ca/~pbarfuss/dekker1971.pdf
2022-06-24 08:21:29 <KipIngram   > Nice - I've opened all that up for post-coffee consumption.
2022-06-24 08:23:02 <veltas      > If you want the cheat sheet Dekker's paper has algol examples at the end which are essentially pseudocode
2022-06-24 08:23:23 <veltas      > Dekker's paper actually explains why this works, which is useful if you want to extend these ideas
2022-06-24 08:24:06 <KipIngram   > I usually like knowing why things work.  Which is why I'm down this vacuum tube rabbit hole right now.  :-)
2022-06-24 08:24:39 <veltas      > I'm half-tempted to write some articles about this because I think I could explain it in a slightly less technical/mathsy way
2022-06-24 08:25:09 <KipIngram   > I'd encourage that - lots of stuff out there is "over-mathed."
2022-06-24 08:25:22 <KipIngram   > Sometimes I think part of what the writers are doing is showing off their math chops.
2022-06-24 08:25:33 <KipIngram   > Instead of trying to reach the largest possible audience of learners.
2022-06-24 08:26:33 <KipIngram   > I guess what it really is though is that their target audience isn't me - they're communicating with the people that are "in their math club" aready.  :-)
2022-06-24 08:27:05 <KipIngram   > One of these days I'm going to have to figure out what a "fiber bundle" is in math, but that's one I bump into pretty often and it glazes my eyes over.
2022-06-24 08:27:10 <veltas      > I think the problem is that I'm an engineer reading essentially an applied maths paper
2022-06-24 08:27:17 <KipIngram   > Yes, same here.
2022-06-24 08:27:40 <KipIngram   > I deliberately took a lot of math, so I know more than a good many folk, but there are still huge areas that are blanks for me.
2022-06-24 08:27:52 <veltas      > Even though I come from a maths background and I'm comfortable with it, I still read it thinking "nobody will understand this", and that's probably true for most of the programmers I work wit
2022-06-24 08:28:29 <KipIngram   > Yeah, a lot of times I just have to keep searching until I find a paper where someone explains whatever it is I'm interested in using less sophisticated math.
2022-06-24 08:40:49 <KipIngram   > When I took all that math in graduate school, what I had in mind was that I later wanted to be able to grok general relativity.  So I loaded up on tensor stuff, linear algebra, coordinate transformations and that kind of thing.  I did ok - I'm comfortable with all that.  But my "big miss" was that I totaly didn't realize how important things like group theory and abstract algebra had become in physics.  I've
2022-06-24 08:40:51 <KipIngram   > gradually sussed out at least a little bit of group theory, but I'm still woefully inept on the abstract algebra stuff.
2022-06-24 08:42:55 <KipIngram   > I don't know how interested you are in physics things, but this is one of the best papers I've ever found:
2022-06-24 08:42:57 <KipIngram   > https://arxiv.org/abs/1810.06981
2022-06-24 08:43:21 <KipIngram   > As far as I can tell, the guy practically "derives" more or less all of physics.
2022-06-24 08:43:47 <KipIngram   > Not every bit, because he drops some terms in a Taylor series expansion, but the part it does cover is remarkably complete.
2022-06-24 08:44:30 <KipIngram   > The terms he keeps don't wind up leading to any "inside the nucleus" physics, but pretty much covers everything outside.
2022-06-24 08:44:42 <KipIngram   > Except gravity.
2022-06-24 08:45:00 <KipIngram   > EM theory, quantum theory, relativity - they all come popping out of the math.
2022-06-24 08:46:18 <KipIngram   > The existence of a maximum speed (c) falls out too.
2022-06-24 08:57:11 <KipIngram   > What really impresses me about the whole thing is how generic his starting assumptions are.  You hear people talk a lot about "the laws of physics being different" in "different universes."  But that paper shows that the laws of physics we've got more or less MUST hold, so if there are "other universes" they're most likely a hell of a lot like ours.
2022-06-24 09:01:10 <KipIngram   > Anyway, the only "assumption" he makes is that there exists at least one conserved quantity.  Doesn't matter what it is - so long as there IS one, all of the conclusions follow.
2022-06-24 09:38:08 <KipIngram   > Oh, it looks like Kahan summation is related to delta-sigma modulation.  I've always been really impressed with delta-sigma modulation; seems almost like getting a "free gift."  :-)
2022-06-24 09:41:46 <KipIngram   > You know, one thing I hadn't realized about vacuum tubes is how limited the list of suitable cathode materials is.  We were actually lucky that there were any, I think.
2022-06-24 09:42:18 <KipIngram   > I'd previously thought that a lot of things would work - that some were just "better" than others.  But it looks like actually only a few will do at all.
2022-06-24 10:03:13 <KipIngram   > There's a book series I'm fond of called The Dresden Files.  urban fantasy stuff, revolves around a wizard living and working in Chicago.  There are seventeen novels so far, out of 25 or so expected.  It's the best stuff I've ever read - highly recommended.  Anyway, along the way the author wrote these little things he called "microfictions" - set in story and released on his website.  Each one is a page and
2022-06-24 10:03:15 <KipIngram   > a half / two pages long or so.  And a couple of them just punch you in the gut a lot harder than something of that length has any business doing.  I think it really underscores how well he's put his fictional world together.
2022-06-24 10:03:35 <dlowe       > There's also a short story anthology
2022-06-24 10:03:42 <KipIngram   > Yes, there are two.
2022-06-24 10:03:56 <KipIngram   > And a couple of short stories that so far have been published only in multi-author anthologies.
2022-06-24 10:04:11 <KipIngram   > And a new novella that's only in audio format.
2022-06-24 10:04:12 <dlowe       > I'm probably one of the few people who knows that the novels are highly structured against the tarot arcana
2022-06-24 10:04:21 <KipIngram   > :-)
2022-06-24 10:04:33 <KipIngram   > I'd like to learn more about that, actualy.
2022-06-24 10:04:49 <KipIngram   > I've read these books to pieces, and I actually help moderate the Reddit sub on the series.
2022-06-24 10:04:57 <KipIngram   > I totally geek out over it.
2022-06-24 10:05:06 <dlowe       > he did his occult research definitely, but maybe not in ##forth :)
2022-06-24 10:05:28 <KipIngram   > Yeah, PM me with anything you feel like sharing.
2022-06-24 10:05:48 <KipIngram   > But for anyone looking for a read, the first book is called Storm Front, by Jim Butcher.
2022-06-24 11:12:00 <crc[dev]    > KipIngram & dlowe, there is a ##dresdenfiles channel, but I don't think anyone other than me has ever been in it
2022-06-24 11:15:56 <KipIngram   > Oh shoot - really?  I'll have to check that out
2022-06-24 11:16:06 <KipIngram   > Like I said - major geek for this stuff here.
2022-06-24 11:18:23 <KipIngram   > Heh - three nicks in it.
2022-06-24 20:34:00 <imode       > anybody have any details on how different nodes in the GA144 chip communicate? is their protocol synchronous, is it based on mailboxes.. how do nodes even hold or execute code, anyway?
2022-06-24 22:21:47 <KipIngram   > That chip is 100% async.  I don't think there's anything at all clocked in it.
2022-06-24 22:22:15 <KipIngram   > There's extensive information about all that online - give me a minute to try to search it up.
2022-06-24 22:23:19 <KipIngram   > Here's a paper on how they boot:
2022-06-24 22:23:21 <KipIngram   > https://www.greenarraychips.com/home/documents/greg/BOOT-02.pdf
2022-06-24 22:23:45 <KipIngram   > Each core has a small a mount of RAM, and there is a way to pass information across the array to a destination core.
2022-06-24 22:24:06 <KipIngram   > Programming it is very different from programming the stuff we're more familiar with.
2022-06-24 22:25:13 <KipIngram   > Each core does very little - to do anything major you have to spread the design across the array; it's almost more like digital logic design than it is regular programming.
2022-06-24 22:25:27 <KipIngram   > I think there's like 64 cells of storage per core or something like that.
2022-06-24 22:28:03 <imode       > I'm wondering what that "way to pass information across the array to a destination core" works. like, is it just saying "I want to write to this word inside of this core"?
2022-06-24 22:28:28 <imode       > are they all operating under the "any core can write to any other core" principal?
2022-06-24 22:29:27 <KipIngram   > It has a name I'm having trouble remembering right now.
2022-06-24 22:29:37 <KipIngram   > Sometime most of a year ago I spent a couple of days noodling into this.
2022-06-24 22:30:03 <KipIngram   > I found a system that was able to run an entire dev system on one Ga-144, with a second Ga-144 along side as the "dev target."
2022-06-24 22:30:11 <imode       > "ether"?
2022-06-24 22:30:21 <KipIngram   > The dev system was spread across the array - these nodes gave the editor, those the compiler, that sort of thing.
2022-06-24 22:30:34 <imode       > https://www.youtube.com/watch?v=2icwrOYbWQ0
2022-06-24 22:30:36 <KipIngram   > Yes - that's right.
2022-06-24 22:30:38 <KipIngram   > Ether.
2022-06-24 22:30:45 <KipIngram   > It's  a "protocol" of sorts.
2022-06-24 22:30:52 <imode       > I'm curious, because that implies that any core has access to any other core.
2022-06-24 22:31:01 <imode       > i.e some form of shared memory with locality.
2022-06-24 22:31:03 <KipIngram   > That's true - it does.
2022-06-24 22:31:15 <imode       > one core can plop data into another core, there's no message bus.
2022-06-24 22:31:23 <KipIngram   > You can send a message some distance this way and some distance that way (right angles).
2022-06-24 22:31:23 <imode       > or rather, no message buffer.
2022-06-24 22:31:34 <imode       > it's not an erlang style system where the cores are isolated.
2022-06-24 22:31:38 <KipIngram   > The ports to the neighbors show up in the memory  map.
2022-06-24 22:31:43 <KipIngram   > And you can execute those locations.
2022-06-24 22:31:58 <KipIngram   > So if you execute a port, and nothing has been written to it, it will sit there and wait until something shows up.
2022-06-24 22:32:15 <imode       > interesting, so it's blocking sends and receives.
2022-06-24 22:32:20 <KipIngram   > Yes.
2022-06-24 22:32:28 <KipIngram   > async handshake.
2022-06-24 22:32:34 <imode       > lit.
2022-06-24 22:32:46 <imode       > so sender blocks until receiver is ready.
2022-06-24 22:32:52 <imode       > receiver blocks until sender is ready.
2022-06-24 22:33:03 <KipIngram   > The asyncrhonous naure is apparently part of how it achieves such  low energy consumption.
2022-06-24 22:33:21 <imode       > yeah, that handshake/blocking data transfer is definitely a property of it being async.
2022-06-24 22:33:29 <imode       > you can "wake" a node up.
2022-06-24 22:33:35 <imode       > or put it to sleep by just blocking.
2022-06-24 22:33:53 <KipIngram   > I can't seem to find that dev system doc now.  It explained a lot of things.
2022-06-24 22:33:59 <KipIngram   > I'll keep nosing around.
2022-06-24 22:34:06 <imode       > if you do I'd love to see it, I'm building a similar system in software.
2022-06-24 22:34:12 <imode       > with a more dynamic topology.
2022-06-24 22:37:27 <KipIngram   > Here you go:
2022-06-24 22:37:29 <KipIngram   > https://www.youtube.com/watch?v=2icwrOYbWQ0
2022-06-24 22:37:52 <KipIngram   > That's it - I'd commented on it here months and months ago - I was able to find it in the logs.
2022-06-24 22:38:00 <imode       > wrong link?
2022-06-24 22:38:14 <KipIngram   > Maybe, but I just pulled it up.
2022-06-24 22:38:18 <KipIngram   > etherforth?
2022-06-24 22:38:29 <imode       > yeah.
2022-06-24 22:38:33 <KipIngram   > Programming GA144 using GA144 only.
2022-06-24 22:38:37 <KipIngram   > That's what I was thinking of.
2022-06-24 22:38:42 <imode       > I'm more interested in how nodes send data to other nodes, how they synchronize, etc.
2022-06-24 22:38:45 <KipIngram   > There may be links provided in the video to more docs.
2022-06-24 22:38:55 <KipIngram   > I think that's where I "started."
2022-06-24 22:40:09 <KipIngram   > Go to www.etherforth.org
2022-06-24 22:40:33 <KipIngram   > I mentioned that further down in the log.  That's where I found the stuff I was talking about.
2022-06-24 22:40:38 <imode       > ah.
2022-06-24 22:40:40 <imode       > nice.
2022-06-24 22:41:00 <KipIngram   > Yes, there's actually some nice documentation there.
2022-06-24 22:41:43 <imode       > this may be what I was looking for, or will at least point to it.
2022-06-24 22:45:29 <KipIngram   > :-)
2022-06-24 22:45:35 <KipIngram   > Happy I could help.
2022-06-24 22:45:58 <imode       > ..I could've just taken a look at the GA144's instruction set.. doy.
2022-06-24 22:46:41 <KipIngram   > One of the comments I made during tha told discussion was that I think the best way to get your arms around programming that thing would be to study good examples.
2022-06-24 22:46:53 <KipIngram   > That dev system is such an example.
2022-06-24 22:47:17 <imode       > yeah, or get a hold of a devboard.
2022-06-24 22:47:29 <KipIngram   > I think it's a whole different "mindset" from most embedded programming.
2022-06-24 22:47:46 <imode       > massively concurrent programming is difficult to think about at high levels.
2022-06-24 22:48:02 <imode       > but with a fixed topology like this, it really functions like a traditional FPGA.
2022-06-24 22:48:18 <imode       > even has a so-called bitstream.
2022-06-24 22:48:19 <KipIngram   > I suspect digital hardware guys (like me) might have an easier time of it - we're taught from the start to think about a lot of simple things happening all over the place at the same time.
2022-06-24 22:49:38 <KipIngram   > I've thought the same thing about multi-core programming too, since it introduces race conditions and timing hazards and so on.
2022-06-24 22:50:06 <KipIngram   > Very different from the simple "one cpu, one step at a time" model.
2022-06-24 22:50:21 <imode       > there are some interesting videos and talks by Dave Ackley.
2022-06-24 22:50:35 <KipIngram   > I'll search that name up.
2022-06-24 22:50:35 <imode       > about what software might look like when you have millions of cores.
2022-06-24 22:50:47 <KipIngram   > Oh, definitely interested.
2022-06-24 22:50:49 <imode       > he's on YouTube and he's trying to solve the programming model problem.
2022-06-24 22:51:22 <imode       > similar structure to the green arrays chip. he's using boards with touchscreens and monitors on them to view the state of a large, 2D planar cellular automaton.
2022-06-24 22:51:23 <KipIngram   > I've thought a lot lately about how CPU design has been driven by the need to run legacy software faster, and I've wondered where we'd be if we'd said "screw it" and just done what seemed smartest without regard for legacy.
2022-06-24 22:51:48 <KipIngram   > Might never have had things like Spectre / Meltdown.
2022-06-24 22:52:05 <imode       > the smartest move would be something that the connection machine engineers, the transputer engineers, green arrays, etc. have figured out: you need to re-spatialize computing.
2022-06-24 22:53:05 <KipIngram   > Our friend here Zarutian_HTC has a big interest in BitGrid.
2022-06-24 22:53:14 <imode       > give me compute coupled to memory, make it tiny, make it clockless, make it so I can just add more and more compute like I add RAM.
2022-06-24 22:53:16 <KipIngram   > Which is another massively parallel idea.
2022-06-24 22:53:36 <imode       > https://esolangs.org/wiki/Bitgrid ?
2022-06-24 22:53:38 <KipIngram   > That's somewhat what BitGrid is.  It's extremely low level though.
2022-06-24 22:53:59 <KipIngram   > That looks like it.
2022-06-24 22:54:21 <KipIngram   > Each cell has four neighbor connections, bi-directional signals.
2022-06-24 22:54:31 <KipIngram   > Each output can be any boolean function of the four inputs.
2022-06-24 22:54:43 <imode       > screams FPGA to me.
2022-06-24 22:54:44 <KipIngram   > That's all - each cell is just a universal logic gate over all of its inputs.
2022-06-24 22:54:55 <KipIngram   > Yes, screamed "sea of gates" to me as well.
2022-06-24 22:55:34 <KipIngram   > The config memory would be arranged to show up as standard RAM, so you could just write the config any way you wanted it.
2022-06-24 22:55:36 <KipIngram   > At RAM speed.
2022-06-24 22:55:51 <imode       > and then processing just "happens".
2022-06-24 22:55:56 <KipIngram   > I figured you'd want all the outputs to show up in RAM somewhere too.
2022-06-24 22:55:59 <imode       > yeah, it's criminal we don't have an architecture like that.
2022-06-24 22:56:05 <KipIngram   > Yeah, it's just a huge combinational network.
2022-06-24 22:56:23 <KipIngram   > Waves of change would just "flow around it."
2022-06-24 22:57:00 <KipIngram   > I was speculating that you might be able to take an existing RAM chip design and just "spread it out" some to make room for the extra connections.
2022-06-24 22:57:11 <KipIngram   > But I'm definitely not a "chip guy."
2022-06-24 22:57:24 <imode       > if you tied compute to refresh rates, hell yeah.
2022-06-24 22:58:07 <KipIngram   > Zarutian_HTC has poked into it a lot more deeply than I have, I think.
2022-06-24 22:58:23 <KipIngram   > He must not be here right now, or I can't imagine he wouldn't have chimed in once we mentioned BitGrid.  :-)
2022-06-24 22:58:33 <imode       > hah, I imagine he'll have a chance. ;)
2022-06-24 23:00:11 <imode       > one of my main gripes is the topology thing. you need to solve the wire crossing problem.
2022-06-24 23:00:54 <imode       > https://esolangs.org/wiki/Wire-crossing_problem
2022-06-24 23:01:07 <imode       > which ultimately leads to "I need to start building some crossing methods and they all suck".
2022-06-24 23:02:16 <imode       > if you're going to be doing that anyway, save yourself the routing by building it as a giant addressable ring.
2022-06-24 23:02:30 <imode       > with the ability to splice.
2022-06-24 23:02:40 <imode       > you could plan the chip out via a space filling curve.