refrences

references/X.com - Onat & Lottes Interaction 1.png.ocr.md

@@ -0,0 +1,113 @@
+# OCR Thread: X.com - Onat & Lottes Interaction 1.png
+
+Post
+OnatTurkcuoglu @onattØ • Apr 30
+Reply
+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.
+$4
+NOTimothyLottes @NOTimothyLottes • Apr 28
+Onat demos his radical language/editor/system for CPU+GPU
+programming: youtube.com/watch?FJ9U_5t„.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+Related thoughts/
+253
+[O] 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.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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]
+02
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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)
+02
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[4] 2-item data stack is an interesting compromise. Something I never
+considered. I left off ripping out the data stack completely.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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
+02
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+[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.
+02
+Onat Turkcuoglu
+@onattØ
+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
+2:53 PM Apr 30, 2025 57 Views
+Post your reply
+NOTimothyLottes @NOTimothyLottes • Apr 30
+Reply
+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.
+01
+OnatTurkcuoglu @onattØ • Apr 30
+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
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+The big industry mistake was factoring into thousands of functions in code,
+instead of just baking all that into a "protocol" of data structures in memory.
+Like OOP member functions to load or mutate one variable = vomit.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+138
+I do all my custom CPU side stuff more like treating the register file like a
+"memory" of which the contents are aliased to different shared structures
+for different purposes across time
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+So the register file is more like an aliased global namespace. And
+"functions" are free of arguments and free of returns. This way of working
+with the HW is way better and easier than the 'C' model.
+01
+NOTimothyLottes @NOTimothyLottes • Apr 30
+In the few cases where you need to reuse small code patterns, those end
+up a compile time macros that inline to different registers, larger pattems
+are already better factored to data
+01
+OnatTurkcuoglu @onattØ • Apr 30
+this is the galaxy-brain take on register-allocation right here - radically
+simpler than what I had in mind:)
+0