alcinnz
When I ponder about string-centric hardware, what am I envisioning? Basically: Imagine a whole OS implemented largely in YACC!
The main "Parsing Unit" processor consists of evaluating lookuptables encoding a pushdown NFA queueing up/fetching instructions for which strings an "Output Unit" should concatenate & where it should route the data!
Occasionally you'd still need to perform arithmetic, for which something on par with the 6502 would often be excessive.
1/2!
alcinnz
Where such a 1980s-era microprocessor isn't excessive (asymmetric crypto, video/audio compression, etc), is relatively infrequent & often involves processing a lot of data. So I imagine something akin to an FPMA full of carry-save adders would be well-suited there!
I can see need for an NPU (I like Mythic's designs!).
We'd need a GPU for visual output, if any. And other peripherals (like a GPS receiver) might need their own microcontrollers.
I'm really drawn to this design!
2/2 Fin!
alcinnz
@steeph I struggle to see how at least my design would benefit from SIMD...
If I say that its microcode is lookuptable-branching, I don't think that'd scale beyond operating a byte-at-a-time. But existing RAM designs can supply those sequential bytes at a rapid rate!
steeph 🎆 ٩(˘◡˘)۶
@alcinnz A string-centric processor would probably benefit a lot from SIMD support. But I'm saying this without understanding how such a processor would work.
alcinnz
Since I see I don't have this clear: That "Parsing Unit", as I envision it, combines the CPU's state with the next byte/bit to lookup its next state.
But oversimplified, but that's the idea!
3/2!
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.