# 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