In our string-centric processor The Output Unit would be our primary communications hub. It wouldn't be all that capable alone, but combined with the Parsing Unit (amongst other coprocessors) it can readily handle most string-processing tasks! How'd we program it?
I'll explore bottom-up.
It'd have various types of "streams" between which we can copy data with optional Lempel-Ziv decompression, as well as sizing, IDing, closing, & "instantiating" (meaning depends on stream type) them.
Some of these stream types would be defined by the machine code, probably with the aid of firmware:
External outputs (which you can perceive)
Poppable stack
RAM (internally subtyped) for rearranging data
2 modes of the Arithmetic Core with "labels" & a single running-"program" each.
Programs (instantiated from RAM) & Processes running on the Parsing Unit, can interrupt Parsing Unit for more sophisticated string processing intermingled in our output.
In early boot I'd build upon Process streams to introduce "File/Directory" streams interacting with an external flash storage device as if it were a network server. Upon this I'd build a Linker script which parses filepaths out of the executables to prepopulate object-capabilities environment with the appropriate files/etc.
And have a Parser script which rewrites textual operators into the Output Unit's flattened opcodes. This would introduce a literal type, surrounded by nil bytes.
The text editor would have special support for marking up string literals so we don't need to include escape characters, instead using text formatting & nil bytes.
A "run" action would open all the output yielded from executing the program being edited (including Arithmetic Core code & normally-voided logs) in new tabs/windows.
Add comment