« first day (580 days earlier)      last day (28 days later) » 

1:51 AM
If the bounding box is all that matters, then a reduced metacell is only a small step in the right direction. Is there any need for the "pixel" part of the metapixel? I hope I'm not missing some obvious display-screen part of the actual GoL pattern.
If you only need tiles that can emulate the four VarLife rules B/S, B1/S, B2/S, and B12/S1, you might be able to fit that into a tile size around 256x256, but it will take a lot of fiddly adjusting and welding. 512x512 looks like plenty of room.
 
cc @KZhang
 
It would be a real bonus if the golfed-down version just "happened" to be a pure power of two, because the full GoL pattern will actually run about as well as the VarLife pattern in Golly -- thanks to Hashlife, it would just take a constant amount more memory.
 
The only real reason why we would need to see the state of a metapixel is if we want RAM to be physically readable. I'm guessing that without this, we might stretch the rules of the original challenge, but it shouldn't affect the actual computer's performance
 
Depending on the design, it might well be possible to build a "display screen" bank somewhere, and a given RAM location would send an extra signal to a specific pixel in the display screen.
The pixels could even be a different size than your VarLife pixels, and it would still work, as long as the period of the display pixels was the same. Connections would have to be custom-made at the GoL level, though, not the metapixel level.
 
That was our original plan (that's basically video memory) but when we made the new RAM we decided it'd be simpler to write directly to it since you could see it
@KZhang maybe connected to another bus if we get those working?
 
2:04 AM
Yeah, I don't think a redesign to include video memory ought to be a high priority or anything -- maybe just a longer-term idea to keep in mind. If you keep the metapixels it's not a terribly difficult project.
 
Since the RAM reading and writing are both controlled by multiplexers, you should just be able to exchange some RAM tiles for a bus to work.
 
I think we decided against having it memory mapped though
Also a display wouldn't need buffering so it wouldn't really be a bus per se
 
A couple of patterns just got added to Golly 3.0, that give a better sense of the unreasonable abilities of the HashLife algo when you feed it properly with all powers of two.
See, e.g., Patterns/HashLife/triple-Snark-wick-extruder.rle.gz.
For the first cycle, it runs at a pretty good clip, but it has a lot of work to do. But after one 262,144-tick cycle, 95% of its work is already done -- if you give Golly enough memory to save all the hashtiles. So after that it speeds up tremendously.
... Just mentioning this in the hope that, whatever the next "golfing-down" stage turns out to be, optimization will just happen to stop at power-of-two boundaries for both space and time.
It's really easy to write Lua scripts for Golly 3.0 that drop gliders in to change the state of your key metacells, and ... possibly? ... play a kind of slow but real-time GoL Tetris.
 
I think we're not too worried about playability in actual GOL, we have the interpreter for the fair weather players
Also we're Pythonistas ;)
 
Sure, Python scripts work in Golly too -- we're just pushing Lua these days because it's available without any extra installing or worrying about versions or 32-bit vs. 64-bit.
 
2:18 AM
Is it LuaJIT?
(just curious)
 
Definitely don't worry about playability, because it might never be playable, I'm not sure -- but it looks to me like the possibility is actually there, after the next golfing-down. I'd love to see the experiment tried.
 
I'm currently trying to make a computer based on 8x8 cells, so that hashlife could go even faster.
 
I didn't add Lua to Golly 2.8, just translated some of the scripts from Python. It's not LuaJIT, just a statically embedded plain-vanilla version 5.3.4 Lua interpreter. Would use it rather than Python for the trivial "drop a glider here" scripts, just because then they'd always work even if Python isn't installed on someone's computer.
8x8 tiles of metacells (or smaller but still vaguely metacell-like circuits) would be a big improvement over 11x11. Oddly enough, 16x16 metacell tiles would be an almost equally huge improvement, from Golly HashLife's point of view.
But 16x16 would have to be combined with a smaller metacell, or it wouldn't count as a golfing-down of the current magnum opus.
And 8x8 circuit tiles actually won't help Golly much, unless you also replace the OTCA metapixels with something with a pure power-of-two period. There will still be too many gigabytes of different hashtiles, so Golly will always end up running out of RAM and garbage-collecting before it hits its super-efficient simulation stage.
 
 
2 hours later…
4:56 AM
@DaveGreene Assuming a Python installation isn't that much of an assumption.
@DaveGreene I don't think 8x8 is doable for many of our logic gates with the current wire/electron design.
 
 
3 hours later…
7:42 AM
/leave
\o/ script fail
 
 
3 hours later…
10:23 AM
@Mego Sounds like KZhang is giving it a try, so probably it's within reach if you allow enough grouped tiles, making 8x16 or 16x16 when they're needed (?)
 
@DaveGreene I don't know how successful a pure 8x8 implementation would be. Many of the logic gates are extremely compact at 11x11. Using a mix of 8x8 and 16x16 tiles would be more feasible.
 
The other option would be to replace the entire "tile" layer of abstraction with logic gates implemented directly in low-level period-1 CGoL circuitry,
but that's a much bigger job -- not terribly difficult but really tedious. Have to re-solve all the timing problems that the 11x11 tiles have already painfully solved, but using known glider reflectors to do the timing adjustments.
 
Yeah, that would be a nightmare to design in pure-GoL. Not impossible, but much more work than using the existing metapixel.
 
There's a scattering of people who would be really good at it -- all the pieces are available. Just a matter of getting a big enough group motivated. (Yes, that's the hard part.)
At a rough guess the whole CGoL replacement for the 11x11s would fit in 512x512 easily, or 256x256 with a lot of painful adjusting and fitting.
But then the state of the circuit wouldn't be very visible, especially zoomed far out, so you'd really need to invent some kind of video memory tiles. That's also been done a bunch of different ways already, some of them even HashLife-friendly.
 
10:58 AM
Just posted a random sample from 2007: conwaylife.com/forums/…
 
11:31 AM
Meant to mention: to avoid timing problems, each circuit tile should probably have a small high-period CGol "clock" gun in it, to guarantee output(s) at the exact right time. Basically it would wait around until all inputs from neighboring tiles have safely arrived, and are stored as boat-bits or the equivalent. Then a signal from the gun would fire up the required logic circuit and send out the result.
There's also a surprisingly small mechanism called a "universal regulator", that can safely align unknown-timing inputs with a clock signal of your choice. Don't think that will be needed, but it's available.
 
 
3 hours later…
3:01 PM
@MartijnPieters Hi, looking for me?
 
3:18 PM
@Cowsquack: yo! Indeed, we should probably use a separate room to not disturb the general populace.
 
3:37 PM
@Cowsquack: And, since you already responded to Carl's email I have my answer. Feel free to chat anyway if you want!
 
 
1 hour later…
4:57 PM
OK the QFT repo is really a disaster
just a hodge podge of stuff
Here's how I think we should redo the repos:
- make a repo for Metafier and ROM creation tools
- make a repo for circuits and the computer
- make a repo for Tetris (Cogol source, QFTASM, ROM)
- transfer qftasm-interpreter and circuitsimulator to the organization as opposed to having them as forks
- delete anything that's literally named "random stuff" (sorry KZhang)
- clean up some of the random Cogol source files
cc @Mego @PhiNotPi
also renaming "WriteUp" to "TetrisWriteUp" might be good since in the future we may have more than one write up :P
 
5:19 PM
@quartata I agree, except that I suggest we just remove the circuit simulator repo. It never got any significant work done, and doesn't really add anything to the project.
 
5:39 PM
ok
transferring qftasm-interpreter needs @El'endiaStarman
other than that I can do the rest myself
actually I can't rename repos
 
6:27 PM
@quartata Only @PhiNotPi can, I think
 
7:02 PM
ok well I think we'll need him for any serious cleanup efforts anyways
 
 
2 hours later…
8:32 PM
hrmmm
so GCC specifies that HI is 2 bytes, but I see a lot of architectures using SI to specify machine words regardless of the word size
I guess I'm worried HI will end up literally being half of a word and being 1 byte
but then at the same time I did specify a short is 16 bits?????
blergh
i'mma just upload this one sec
> On most machines, if_then_else expressions are valid only to express conditional jumps.
thank you based gcc for not making my life miserable
 
9:02 PM
OK after doing an RTL dump it turns out that HI is the correct mode
on a 64-bit system it uses DI (double integer) so at least I think so
 
9:14 PM
@Mego currently having to reinstall and reconfigure Git but once I'm done you'll be able to find the backend here under gcc/config/qftasm
 
9:46 PM
@quartata Excellent, thanks
 
@Mego this will be of interest to you: gcc.gnu.org/onlinedocs/gccint/Back-End.html
Start with the machine description part
Also take a peek at the Moxie and MMIX backends
They're very simple
 

« first day (580 days earlier)      last day (28 days later) »