113 lines
4.9 KiB
Markdown
113 lines
4.9 KiB
Markdown
# 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 |