6.9 KiB
← Back to Twitter thread index
title: "@onatt0 [3] I got side tracked by building a language that could be assembled fr" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/1917646466417381426" post_id: "1917646466417381426" timestamp: "2025-04-30 18:25:20" post_count: 22 reply_count: 2 repost_count: 0 like_count: 1 view_count: 125
@NOTimothyLottes — @onatt0 [3] I got side tracked by building a language that could be assembled fr
Post 1 (2025-04-30 16:13:33)
Forgot to mention in the heat of presentation, the initial textual language was heavily influenced by one of your past forth-like languages. Though I've built upon that foundation, I would have taken many wrong turns without your guidance, thank you so much.
Post 2 (2025-04-30 18:10:43) — reply to Post 1
@onatt0 Related thoughts/ [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.
Post 3 (2025-04-30 18:19:07) — reply to Post 2
@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]
Post 4 (2025-04-30 18:22:55) — reply to Post 3
@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
Post 5 (2025-04-30 18:25:20) — reply to Post 4
@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)
Post 6 (2025-04-30 18:27:04) — reply to Post 3
@NOTimothyLottes oh dang realized i forgot to mention that part in the talk:) symbol name encoding for this iteration is 63bits(7bits*9chars) + 1bit extend(which highlights the word) extension can be at either end, say VFRAMEADDR AFRAMEADDR VPLANEADDR or VPACK.RING VPACK.HEAD VPACK.TAIL
Post 7 (2025-04-30 18:35:00) — reply to Post 5
@onatt0 [4] 2-item data stack is an interesting compromise. Something I never considered. I left off ripping out the data stack completely.
Post 8 (2025-04-30 18:40:32) — reply to Post 7
@onatt0 [5] Can do this instead, a. Track a "top" register (number) b. Use symbols to override top register c. Have push (store) just advance top to next reg (in circular queue) Gets to easy unnamed arguments
Post 9 (2025-04-30 18:45:00) — reply to Post 5
@NOTimothyLottes IMO code compilation is inherently sequential+ "execution contextual", dynamic logic execution to get the binary as the essence vs a static lang
codegen 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?
Post 10 (2025-04-30 18:45:38) — reply to Post 8
@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 ...
Post 11 (2025-04-30 18:47:28) — reply to Post 10
@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.
Post 12 (2025-04-30 18:49:40) — reply to Post 11
@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.
Post 13 (2025-04-30 18:52:21) — reply to Post 12
@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"
Post 14 (2025-04-30 18:53:48) — reply to Post 12
@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
not only you have to keep the whole stack around with replicated state, it limits to serialized execution instead of parallel
Post 15 (2025-04-30 18:55:33) — reply to Post 13
@NOTimothyLottes simply brilliant!
Post 16 (2025-04-30 18:59:14) — reply to Post 9
@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
Post 17 (2025-04-30 19:03:11) — reply to Post 16
@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.
Post 18 (2025-04-30 19:04:57) — reply to Post 14
@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.
Post 19 (2025-04-30 19:05:05) — reply to Post 6
@NOTimothyLottes a much better encoding is possible next iteration is going to be
16bits4words if you need multiple words(last word=15bits) 7bits9chars if its a unique/short name(to not clutter the 16-bit dictionary-space)
64K*4 words should be enough for most cases
Post 20 (2025-04-30 19:10:53) — reply to Post 19
@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.
Post 21 (2025-04-30 19:13:59) — reply to Post 20
@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$.
Post 22 (2025-04-30 19:15:11) — reply to Post 18
@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
ofc a lot of people want portability so we went the boring route