Thinking About Timing Issues

2025-02-23

Feb 24, 2025

I think we need more direct control and thinking about concurrency and timing issues, but, no, this article is only supposed to argue that we're crushing that poor little CPU down there with all sorts of baubles and extra chip real-estate for supporting the concept of "functions". That article isn't supposed to argue the uber argument. It is meant to argue just a piece of the uber argument.

A simple CPU implements sequential subroutines. A CPU is sequential even today,,, but, we've overloaded it with MMUs, caches, opcode-level concurrency, etc. to provide scaffolding for function-based programming.

If we stripped all of that fluff out of there, would we have room for many more bare CPUs with their own private memory?

We have access to techniques and hardware now that we didn't have 50 years ago.

All of that extra fluff that we've loaded onto the shoulders of simple CPUs is causing myopia. When all you've got is a hammer, then everything looks like a nail. When you are forced to use only one paradigm - functions - then everything has to be forced into the functional mould, regardless of suitability.

Functions are not the be-all-and-end-all of programming. The functional paradigm is useful,,, but, functional programming is not the only way to create sequential assembler opcodes for scripting the actions of CPUs.

Can we create programs using IDEs that support multiple paradigms? Can we do so with the tools we've got today, even though most of our tools are function-based and ASCII-based?

I argue "yes" and am showing how to do that.

It's easy with 1st-class functions and queues and tools based on PEG parsing.

We shouldn't feel forced to make every programming "language" sequential, even though the low-level hardware CPU is sequential. We need many different programming "languages" and we need new programming notations that go beyond the "language" mould. Yet, we continue to make every programming language sequential, just like in the good old days of cave dwellers.

Sequentialism is how you make a single node within a non-sequential network.

But, we're faced with the "new" problem of making non-sequential networks composed of internally-sequential nodes.

We're tying our hands behind our backs by using only sequential-function-based ideas for building networks and little networks.

50 years ago, the problem was how to make a computer using only one CPU.

Today, though, the problem is completely different - how to make computers using bowls full of CPUs. And how to make robots and internets and IoTs, etc., using bowls full of CPUs, GPUs, computers, FPGAs...

In fact, I have come to the conclusion that just the word “computer” is overly biased, subconsciously suggesting that these simple machines should only be used for compute-ing. I’ve started calling them REMs - Reprogrammable Electronic Machines - to emphasize the idea that we can use CPU-based hardware devices for more than one purpose, beyond just being Radio Shack handheld calculators for compute-ation.

The fundamental innovation isn’t that we’ve created machines that can be programmed - we’ve been doing that for centuries. The innovation is that we’ve created machines that can be re-programmed and re-purposed.

We invented a hardware thing - a CPU - that executes actions based on scripts of sequential opcode instructions in its memory.

The original idea was that we could use zillions of these things - CPUs - for building interesting devices. Due to cost, though, cave dwellers were forced to use only one of these things at a time, and, were forced to squeeze blood from a stone. Today, we can do better, but, we continue to use cave dweller ideas from 50 years ago, like using textual programming languages as IDEs for programming networks of these things. These cave-dweller programming languages force us to use cave-dweller concepts like operating systems, instead of simply poking simple assembler scripts into these REMs.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Thinking About Timing Issues

2025-02-23

See Also

Discussion about this post

Ready for more?