ed/manual_slop
Private
Public Access
0
0
Fork 0
Code Activity
Files
master
manual_slop/docs/twitter/1917646466417381426/thread_data.json
T
ed dc99722bf8 saples updated
2026-07-05 19:09:22 -04:00

372 lines
14 KiB
JSON
Raw Permalink Blame History

{
"root_post_id": "1917646466417381426",
"posts": [
{
"post_id": "1917613300902146419",
"author": "on@☦️",
"handle": "onatt0",
"text": "Forgot to mention in the heat of presentation, the initial textual language was heavily influenced by one of your past forth-like languages. \nThough I've built upon that foundation, I would have taken many wrong turns without your guidance, thank you so much.",
"timestamp": "2025-04-30 16:13:33",
"media_urls": [],
"reply_to_id": null,
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 5,
"view_count": 308
}
},
{
"post_id": "1917642786804785230",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 Related thoughts/\n[0] Having a low upper bound on the maximum complexity allowed in a program enables so much simplification. One can always move complexity into data, while keeping tight codebases.",
"timestamp": "2025-04-30 18:10:43",
"media_urls": [],
"reply_to_id": "1917613300902146419",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 2,
"view_count": 112
}
},
{
"post_id": "1917644904055910502",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [1] Seems like you group symbols into pages where each page can have a string (shared with all symbols in the page), which when pared with limited fixed maximum symbol string size, is an elegant way of effectively supporting larger naming [I'll probably steal that idea next time]",
"timestamp": "2025-04-30 18:19:07",
"media_urls": [],
"reply_to_id": "1917642786804785230",
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 0,
"like_count": 1,
"view_count": 93
}
},
{
"post_id": "1917645859791200562",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [2] I'm also a big fan of how you used 16:9 aspect to auto render all the debug info, symbol tables, disassembly, etc, alongside the source. I think many people are probably lost in the speed at which you can manipulate and test ideas while working on the source",
"timestamp": "2025-04-30 18:22:55",
"media_urls": [],
"reply_to_id": "1917644904055910502",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 88
}
},
{
"post_id": "1917646466417381426",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [3] I got side tracked by building a language that could be assembled from on the GPU in SIMD. However now I ask myself if that is just adding \"complexity\", because if programs are bounded in size, why not just focus on CPU non-parallel nested factoring (aka the forth-like way)",
"timestamp": "2025-04-30 18:25:20",
"media_urls": [],
"reply_to_id": "1917645859791200562",
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 0,
"like_count": 1,
"view_count": 125
}
},
{
"post_id": "1917646904277754258",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes oh dang realized i forgot to mention that part in the talk:) \nsymbol name encoding for this iteration is 63bits(7bits*9chars) + 1bit extend(which highlights the word) \nextension can be at either end, \nsay VFRAMEADDR AFRAMEADDR VPLANEADDR\nor VPACK.RING VPACK.HEAD VPACK.TAIL",
"timestamp": "2025-04-30 18:27:04",
"media_urls": [
"https://pbs.twimg.com/media/GpzZmVBW8AALxll?format=png&name=orig"
],
"reply_to_id": "1917644904055910502",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 27
}
},
{
"post_id": "1917648900556558768",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.",
"timestamp": "2025-04-30 18:35:00",
"media_urls": [],
"reply_to_id": "1917646466417381426",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 87
}
},
{
"post_id": "1917650289978454504",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [5] Can do this instead,\na. Track a \"top\" register (number)\nb. Use symbols to override top register\nc. Have push (store) just advance top to next reg (in circular queue)\nGets to easy unnamed arguments",
"timestamp": "2025-04-30 18:40:32",
"media_urls": [],
"reply_to_id": "1917648900556558768",
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 0,
"like_count": 3,
"view_count": 108
}
},
{
"post_id": "1917651417487036446",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes IMO code compilation is inherently sequential+ \"execution contextual\", dynamic logic execution to get the binary as the essence vs a static lang\n\ncodegen with execution on GPU could work as 2-items(vreg)/stack and 32K cells per lane for AI to map code to data instead of weights?",
"timestamp": "2025-04-30 18:45:00",
"media_urls": [],
"reply_to_id": "1917646466417381426",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 0,
"view_count": 21
}
},
{
"post_id": "1917651574354030636",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [6] You mentioned VK is most \"form filling\" which I think is an accurate description. For most \"C\" like APIs I like to just lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls ...",
"timestamp": "2025-04-30 18:45:38",
"media_urls": [],
"reply_to_id": "1917650289978454504",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 98
}
},
{
"post_id": "1917652037078065160",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [7] They key concept here is that \"common\" arguments like the device are pushed onto the tape using store duplication when they are known (after device creation). So it's preemptive scatter, so later at call time there is no argument gather.",
"timestamp": "2025-04-30 18:47:28",
"media_urls": [],
"reply_to_id": "1917651574354030636",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 2,
"view_count": 110
}
},
{
"post_id": "1917652589358858332",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [8] Likely the majority of C/C++/OOP/bloatware is just shuffling data around in argument gather to support the concept of data stacks on HW that has no physical data stack.",
"timestamp": "2025-04-30 18:49:40",
"media_urls": [],
"reply_to_id": "1917652037078065160",
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 1,
"like_count": 3,
"view_count": 209
}
},
{
"post_id": "1917653265329594372",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 [9] Could just pre-layout call arguments in order of usage, leverage data compression at init-time to unpack into memory before run-time. No more code to shuffle arguments, or set registers to immediates, etc. Just a common (cached) pre-call to consume args from the \"tape\"",
"timestamp": "2025-04-30 18:52:21",
"media_urls": [],
"reply_to_id": "1917652589358858332",
"quote_of_id": null,
"metrics": {
"reply_count": 2,
"repost_count": 0,
"like_count": 4,
"view_count": 135
}
},
{
"post_id": "1917653631651729876",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes holy truthnuke - and people think C is the optimal state of possible runtimes when it's a very limited runtime to have state mixed call/data-stacks\n\nnot only you have to keep the whole stack around with replicated state, it limits to serialized execution instead of parallel",
"timestamp": "2025-04-30 18:53:48",
"media_urls": [],
"reply_to_id": "1917652589358858332",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 0,
"view_count": 80
}
},
{
"post_id": "1917654071323857138",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes simply brilliant!",
"timestamp": "2025-04-30 18:55:33",
"media_urls": [],
"reply_to_id": "1917653265329594372",
"quote_of_id": null,
"metrics": {
"reply_count": 0,
"repost_count": 0,
"like_count": 0,
"view_count": 48
}
},
{
"post_id": "1917654997895983255",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 So for x86 I've many times written code gen with extra nop-prefix padding to fix all instructions to a multiple of known 32-bits. Which means you know in advance sizing of everything, then you can easily do parallel code generation. So need not necessarily all be serial",
"timestamp": "2025-04-30 18:59:14",
"media_urls": [],
"reply_to_id": "1917651417487036446",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 43
}
},
{
"post_id": "1917655990792560843",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 However I'm often building then instantly using code while generating a baked binary to use later, so that regard much is inherently serially dependent. This bootstrapping technique is perhaps one the great things to learn from things like color forth IMO.",
"timestamp": "2025-04-30 19:03:11",
"media_urls": [],
"reply_to_id": "1917654997895983255",
"quote_of_id": null,
"metrics": {
"reply_count": 0,
"repost_count": 0,
"like_count": 1,
"view_count": 58
}
},
{
"post_id": "1917656437473399108",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 I laugh when people say C is like assembly, they are missing what we actually did in assembly back then, which was all registers and globals and gotos, no stacks. It's radically different than good assembly.",
"timestamp": "2025-04-30 19:04:57",
"media_urls": [],
"reply_to_id": "1917653631651729876",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 1,
"like_count": 3,
"view_count": 156
}
},
{
"post_id": "1917656470444790255",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes a much better encoding is possible\nnext iteration is going to be\n\n16bits*4words if you need multiple words(last word=15bits)\n7bits*9chars if its a unique/short name(to not clutter the 16-bit dictionary-space)\n\n64K*4 words should be enough for most cases",
"timestamp": "2025-04-30 19:05:05",
"media_urls": [],
"reply_to_id": "1917646904277754258",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 0,
"view_count": 20
}
},
{
"post_id": "1917657931375313017",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 It would be interesting to size stuff so the limits align with instruction cache size limits. Build something where the expectation is a hit in the I$ once it's warm after the context switch and move everything else to data complexity.",
"timestamp": "2025-04-30 19:10:53",
"media_urls": [],
"reply_to_id": "1917656470444790255",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 34
}
},
{
"post_id": "1917658709192306788",
"author": "NOTimothyLottes",
"handle": "NOTimothyLottes",
"text": "@onatt0 Same could apply for non-bulk data, ie the stuff you'd possibly want human readable annotation on. Make it sized to practical L2$ limits, or fix it to at most the shared L3$.",
"timestamp": "2025-04-30 19:13:59",
"media_urls": [],
"reply_to_id": "1917657931375313017",
"quote_of_id": null,
"metrics": {
"reply_count": 0,
"repost_count": 0,
"like_count": 1,
"view_count": 48
}
},
{
"post_id": "1917659010024587634",
"author": "on@☦️",
"handle": "onatt0",
"text": "@NOTimothyLottes when C became *the* execution model, it restricted all future hardware, HW gets built with how the C compiler will compile to it instead of what's ultimately a good design and a malleable macro-lang to map to HW\n\nofc a lot of people want portability so we went the boring route",
"timestamp": "2025-04-30 19:15:11",
"media_urls": [],
"reply_to_id": "1917656437473399108",
"quote_of_id": null,
"metrics": {
"reply_count": 1,
"repost_count": 0,
"like_count": 1,
"view_count": 40
}
}
],
"source_url": "https://x.com/NOTimothyLottes/status/1917646466417381426",
"source_urls": [
"https://x.com/NOTimothyLottes/status/1917646466417381426",
"https://x.com/NOTimothyLottes/status/1917644904055910502",
"https://x.com/NOTimothyLottes/status/1917645859791200562",
"https://x.com/NOTimothyLottes/status/1917642786804785230"
],
"member_targets": [
"1917642786804785230",
"1917644904055910502",
"1917645859791200562",
"1917646466417381426"
]
}
View Git Blame Copy Permalink