The group is a group dedicated to the M68000 microprocessor, which is generally classed as a mixed 16-bit and 32-bit processor, and this member of the group was obstinately using all sorts of bad argument technique to insist that the 68000 must be classed strictly as a 16-bit CPU, while accusing anyone who opposed his opinion of using the very same false argumentation techniques that he was using.
I looked at his profile on his FB home, and noted two things -- he registered the user to create a certain group, and he seems to claim some virtue in "being mean to FB users". LOL.
I could report that Facebook user and probably get him kicked off, but I won't, for three reasons.
One, I have been similarly unreasonable in flame wars. I try to shut my unreasonableness down as soon as I notice it, even if it means dropping out of the flame war.
Two, putting up with unreasonable behavior is a necessary civility. If we don't allow another person's misbehavior, we have no claim to any right to behave unreasonably, and pretty soon society descends into war.
Three, we often learn useful things from unreasonable behavior.
Unreasonable behavior.
When I think of unreasonable behavior, an example from the Bible comes to mind in the incident of Baal-peor, when a man and a woman were summarily executed for adultery. The record of the Old Testament is not very complete, and it's hard to be completely sure that the killing was done to stop the plague of sexually transmitted disease that people of Moab had started among people of Israel, but careful reading does indicate that was most likely the case.
And it's a classic example of unreasonable behavior, begetting unreasonable behavior, echoing to the present when ordinary citizens who stray outside without reason in Europe have reportedly been summarily shot. A couple of things closer to home for me (Kantō area) that I get from mainstream news reports:
- pretty much every member of one group of young people who had a "live event" (dance party) last week has tested positive for COVID-19;
- one man who tested positive deliberately went out and got in the face of innocent salesclerks and others, infecting at least two of the people he came into contact with.
My tendency to diverge from the topic is pretty unreasonable, too. Back to the topic.
CPUs are yet another thing one should never use a one-dimensional yardstick to compare.
I know that there have been real, if not commercial) implementations of strictly 8-bit
CPUs.
But that requires an 8-bit address space, and it's hard to fit much of a program in 256 bytes of program + data. Well, Harvard architecture would allow 256 bytes max of data space and 256 bytes of program space, but it's still really tight, and the programs you could write in that much space are likely to be better implemented with discrete logic or programmable logic devices.
Okay, it would be a fun topic to pursue, and might even be worth a master's thesis or such. But it would also be unreasonable for anyone who is not retired, in the present socio-economic environment.
That is, until someone does it and proves that there is some useful application for it, it would be unreasonable.
RISC processors were once an unreasonable idea, too.
So, all the so-called 8-bit CPUs you have used are mixed size CPUs, because they have address spaces larger than 256 bytes.
And we probably should admit that there is no useful strictly 4-bit CPU to be built.
A CPU with a 4-bit-wide instruction set? Yes, those exist. A CPU with 4-bit-wide registers? Yes, those exist. A CPU with a 4-bit-wide address space? Hmm. Okay, there are parts of larger CPUs that actually consist of such things.
Maybe we should have more open minds, instead.
Back to 8-bit CPUs. Most such are characterized as 8-bit for their data register width and basic instruction width, and have wider addresses. That's three dimensions, data register width, basic instruction width, and address width.
There are other dimensions, such as number and type of registers, orthogonality of instruction architecture, generalization and specialization of instruction set, etc.
But, even if you line up a bunch of these measures, you really don't end up knowing that much about a CPU until you start looking at well-written code for it and comparing it with good code for other processors.
To that end, I've been working on a set of common library functions that could be useful in comparing processors. I'm borrowing the code for an old Forth interpreter to center the library around, but it will not be limited to the Forth paradigms. If I work it well, it should produce a Forth-like interpreter that will be portable across the CPUs, and it should allow others to produce similar library sets for other CPUs.
I should be posting the beginnings of the code later today, for the 6800, the 6801, the 6809, and the 68000, on my OSDN account. I'll link to that from here.
[JMR202007181941:
Here is the project on OSDN, but it's stuck at a place where the 68K code is not yet up:
https://ja.osdn.net/projects/splitstack-runtimelib/
]
