Bitgrid

sing the cell latches as "Isolinear Memory"[2] are optimizations to consider. BitGrid Simulator - I've written Pascal[3] and React[4] based simulators for a basic bit grid. I need to write one in Verilog, and get it running on an FPGA. Even better would be an emulator running on a Raspberry Pi Pico, it would be slow as snot, but you could easily tile them to get more performance at $4/node. BitGrid Tiny Tapeout - I need to build an actual chip, so I can get real world performance numbers to use. It could be either way more efficient than anything else out there, or it could be abysmal... as the man at the start of Dirty Harry says "I've gots to know" BitGrid object format - Bitgrid needs to be programmed from a directed acyclic graph of logical binary operations. I need to settle on a text and binary format that makes sense. How would you write do this? I could really use a push here. BitGrid compiler - I need to figure out how to generate the files above from source code in something more familiar. Eventually I'd like both TinyGrad and LLVM to target BitGrid. BitGrid story - I need to take my blog [5] and various mentions here and elsewhere, and put them into a Book, YouTube videos, etc. The whole BitGrid saga has been out in public for over a decade. Currently the Bus Number is 1, and I'm not in great health... it would be awesome to increase this number. ---- Capability Based Security - Computer Security is a SOLVED problem, I've been trying to keep that knowledge alive and discoverable by pushing it where I can. I'm hoping to run Genode as my daily driver, but I'm not there yet. -- Open source Data Diodes... I think 2 Raspberry Pi computers each with Ethernet, and a unidirectional driver could make an effective open source data diode. -- Phase Coherent SDR - I'd like to build an N channel phase coherent SDR, it should be possible to build it for somewhere around $(100+20N) -- Metamine - briefly there appeared a language called MetaMine, and it was magic. It could mix declarative and imperative code, and had sane rules for doing so. It represented the most powerful language I ever saw. It would be nice to bring those features into a Pascal or Python or Forth/Stoic environment. -- [1] https://esolangs.org/wiki/Bitgrid [2] https://bitgrid.blogspot.com/2024/09/bitgrid-and-isolinear-m... [3] https://github.com/mikewarot/Bitgrid [4] https://github.com/mikewarot/bitgrid-react-app [5] https://bitgrid.blogspot.com/

entirely of D flip-flops and 16:1 multiplexers. (I lack the funds to do a TinyTapeout, but started going there should the money appear) All the computation happens in cells that are 4 bit in, 4 bit out Look up tables. (Mostly so signals can cross without XOR tricks, etc) For the times you need a chunk of RAM, the closest I got is using one of the tables as a 16 bit wide shift register, which I've decided to call isolinear memory[6] You can try the online React emulator I'm still working on [1], and see the source[2]. Or the older one I wrote in Pascal, that's MUCH faster[3]. There's a writeup from someone else about it as an Esoteric Language[4]. I've even written a blog about it over the years.[5] It's all out in public, for decades up to the present... so it should be easy to contest any patents, and keep it fun. I'm sorry it's all a big incoherent mess.... completely replacing an architecture is freaking hard, especially when confronted with 79 years of optimization in another direction. I do think it's possible to target it with LLVM, if you're feeling frisky. [1] https://mikewarot.github.io/bitgrid-react-app/ [2] https://github.com/mikewarot/bitgrid-react-app [3] https://github.com/mikewarot/Bitgrid [4] https://esolangs.org/wiki/Bitgrid [5] https://bitgrid.blogspot.com/ [6] https://bitgrid.blogspot.com/2024/09/bitgrid-and-isolinear-m...

ortion of computer science. Of course both share the same insane foundation: The set of FSAs define a cell space of infinite size. All FSAs are identical in terms of state-transition function, or rule-set. It's that one "simplification" that relegates them to the domain of code golf. [1] https://github.com/mikewarot/Bitgrid [2] https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton [3] https://en.wikipedia.org/wiki/Nobili_cellular_automata pps: If anyone wants to run with the idea of a BitGrid, I'd appreciate it

, the latency for a given stream would be horrible, but you could have millions of parallel streams. To do this, you have to map the directed graph to hardware. In an FPGA this can take days because of the special modules, etc. This makes programming a nightmare. With a BitGrid, you can just use a greedy mapping algorithm, and Bob's your Uncle. Because every cell is essentially the worlds smallest Excel Sheet cell, it's easy to know all of the dependencies for any given cell. You can move cells, rotate them, flip and mirror them if you need to maximize the utilization of hardware, or want to wall off a given graph inside walls for isolation. Until recently, I've always thought of it as a chip, but recently I've come to see that you could just as well take a farm of RP2040 chips and have them all running slow simulators of a fairly huge BitGrid chips, and network them through their I/O pins to make an arbitrary size array, cheap! The BitGrid topology thus becomes a universal computing solvent. Scaling anything that can be expressed as the directed graph can be run very slowly on a CPU with a lot of RAM/Disk, or quickly on silicon, with identical results. I think this could scale to PetaFlops quite cheaply (a few runs through TinyTapeOut then scaling up) [1] https://github.com/mikewarot/Bitgrid [2] https://mikewarot.github.io/Bitgrid_C/bitgrid_sim.html [3] https://esolangs.org/wiki/Bitgrid

told with niceties.[4] [1] https://mikewarot.github.io/Bitgrid_C/bitgrid_sim.html [2] https://github.com/mikewarot/Bitgrid [3] https://tinytapeout.com/ [4] https://github.com/mikewarot/RateMyPhotos

r race conditions. If you give up and embrace latency, and the wasting of gates to route signal, you end up with a homogenous, isolinear core. (The same in any linear direction) You can rather easily shift a part in any direction, rotate it, and flip it. You can route around defective cells (assuming the shift register chain doesn't break, of course). Latency goes to hell, but because every single operation is pipelined, your throughput can go through the roof, none of the data lines ever has to make it all the way across the chip, except the clock signals. The shift registers, and only have to load things before the computing starts, so they don't have to be fast at all. [1] https://mnemocron.github.io/2023-12-08-DIY-FPGA-diary-1/ [2] https://esolangs.org/wiki/Bitgrid [3] https://github.com/mikewarot/Bitgrid [4] https://hackaday.com/2012/11/01/discrete-fpga-will-probably-... [5] https://web.archive.org/web/20150621104100/http://blog.notdo... [6] https://github.com/Arachnid/dfpga/tree/master

ove the I/O around. The aforementioned dependency tracing makes it possible to prove the functionality conforms to the desired logical expression graph. I need a kick in the pants to get the rest of this thing figured out. As near as I can tell, the only problems are my own writers block. [1] https://esolangs.org/wiki/Bitgrid [2] https://github.com/mikewarot/Bitgrid