Paged through some and found an article on Speech Recognition [0]:
Most interesting sentence: "Currently, it is not likely that such techniques would be used for domestic surveillance."
Philosophical Issues
The specter of Big Brother may not be of concern in
Western society today, but the evolution of distributed
intelligence among machines with speech-recognition
capability certainly provides the technical base for
monitoring our activities. In fact, the U.S. National
Security Agency has developed what may be the world's most
advanced speech-recognition algorithms. This system spots
keywords in intercepted verbal transmissions from
"unfriendly" nations. Currently, it is not likely that
such techniques would be used for domestic surveillance.
But speech technologists as well as the public must be
aware of the potential loss of privacy.
This was five years before a 10000 dollar dedicated speech recognition card would be available for home PC's, I remember when we got one for testing when I was working during college at IBM and it was huge like those double slot graphics cards one can buy today, now we can do the equivalent on our phones - it's hard to predict sometimes how fast or where technology is going to advance.
By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979, but it would indeed take until 68020 in 1984 for the CPU to have a 32bit bus and for 32bit operations to not be internally split into 16bit ones.
I admire the foresight of Motorola in making the ISA itself 32bit from the get go.
When I was in college, studying electrical engineering, we used a 68K (I forget the exact version) in our microcomputers course. In lab, the "computers" we worked on were hand assembled, wire-wrapped from individual chips. Quite the site to look at, especially considering that it fit in the same size as a then standard desktop form.
What I do remember is that while 32-bit ISA, the data bus was 16-bit. We had both hardware and software debuggers. The hardware debugger was basically flipping a switch from going from a regular clock to a single step with set of hex displays on the front of the computer that allowed you to see what was on the databus, no internal CPU state. The software debugger allowed you to see CPU registers, display memory. No stack trace.
One of our projects was to write a resident monitor, maybe more analogous to a super micro kernel. Because the monitor ran in supervisor mode, while normal code ran in user mode, and our software debugger also ran in supervisor mode, we couldn't use the software debugger for our monitor. We could only use the hardware debugger. I got really good at decoding 68K instructions from reading the hex display while single-stepping.
A silly aside from that last comment; We built our monitor on then modern PCs, specifically, I had a laptop running FreeBSD, because it had a 68K emulator available. To get our assembled code to the micro computer, we had to transfer it over a 1200 baud serial connection, and it took around 30 minutes to transfer our monitor before we could even test. So, we heavily utilized the emulator which was nearly instantaneous. We had run all of our tests against the emulator and everything looked good. We were still in lab at around 2AM, and our professor walks in and asks how we were doing. I responded we were doing great, and had just uploaded our latest code to test. Our test on the actual hardware failed spectacularly. Started using the hardware debugger to find out why, and it turned out to be an addressing issue (the instruction was using the default 16-bit addressing instead of the intended 32-bit addressing). It was literally a 1-bit bug. I manually edited the memory and reran and it was fine. There might have also been a jokingly light back-hand across the face of the team member that wrote the routine that failed.
According to Sophie Wilson, one of the reasons Acorn decided to go ahead with their own CPU design was the fact that in 1983 the 68000 and other contemporary CPUs were bottle-necked on memory access.
Of course within a few years _everything_ was bottle necked on memory access and the advantages of processors that could do memory access in few cycles (like the 6502 or early ARM) doesn't mean much anymore, as CPU speeds easily outstripped memory speeds.
Wider memory buses were still less bottlenecked than narrower though. See the transition from 32 to 64 to 128 to 256.
POWER9 has an absurd setup which is 192 bits wide at the CPU (2 controllers each with 4 24 bit DMI interfaces), but each DMI has a 256 bit path t memory.
> By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979,
Huh? The second paragraph states: "First, let's define our terms. A 32-bit microprocessor has a full 32-bit architcture, a full 32-bit implementation, and a 32-bit data path (bus) to memory." (And then the author spells out what each of those three things means individually.)
IIRC, the 68000 missed both the 32-bit implementation and the data path.
Interesting to note though, that Intel's later 80386SX product would NOT quality for the article, even though it's a compatible reduction of a chip that does. (The SX version of the product had a 16-bit bus and was physically closer to a 80286 in terms of external hardware interface.)
For some history—the early Macs in 1984 used 24-bit addressing. The 68000 itself had a 24-bit address bus, but the address registers were 32 bits. So you could use the top 8 bits for some extra data, and programs actually did this (including ROMs/system software for early Macs). This meant that your memory would max out at 8 MiB, with the other half of the address space used for something else (ROM?).
When System 7 came out, 32-bit addressing became available but not all software was “32-bit clean”. So you could enable or disable 32-bit addressing in the memory control panel. This is similar to the A20 gate on IBM PCs.
By 1993 or so the hardware was no longer built to support 24-bit addressing. PowerMacs followed soon after.
Ya I miss the 68000. It was the first assembly language that I learned. It was much closer to RISC than x86 is, so there were plenty of registers and the instructions were fairly generic so it was straightforward to map C code almost directly to assembly. The "32 bit clean" stuff caused a lot of bugs for years after 32 bit memory arrived though.
What really killed it though was perceived slowness. Apple insisted on shipping generations of Macs with crippled busses running at half the bit width of the CPU and/or at reduced frequencies.
I remember the very fastest Macs in the early 90s not being able to even run a scrolling 2D game at 640x480 in 8 bit color because it just wasn't a priority. Meanwhile a 486 could run DOOM in 320x240. We had to wait until the 60 MHz PPC 601 arrived, and even it struggled with 640x480 graphics (the lowest resolution available). On top of that, most software was still emulated 68000, so the perceived slowness of Macs continued until Steve Jobs returned and introduced the colored iMacs.
I eventually came to love x86 assembly for the brief time I used it though. It has so many easter egg instructions for moving bytes around wider registers and getting free side effects with memory access that it felt like there was always another way to gain a bit more performance out of hand-rolled loops.
Of course that's all gone today, because instruction sets are so.. byzantine that a good compiler will usually beat hand-rolled assembly. That's because the real processing happens as RISC beneath microcode so a human can't really know the optimal way to string instructions together to keep the pipeline full or avoid cache misses. Also the SIMD stuff expanded the solution space to such a degree that it's almost pointless to do anything directly. Better to use a vector language like MATLAB and compile to SIMD accelerated C or go to GPU processing instead IMHO. Otherwise you're perpetually struggling with premature optimization and can't work at a productive level of abstraction.
The address space of AMD64 was designed so that both the upper and lower spaces of the address are used when using less than 64 bus lines specifically to address this problem.
That only ensures the programmer fixes the pointer before dereference.
Tagged pointers that don’t make it to the bus are still a compatibility problem. It means malloc() can’t return an address overlapping the tagged bits.
> and apply a mask before using it for memory accesses
So it never goes onto the address bus. So it never causes an addressing issue.
The 24-bit issue of the 68000 is fundamentally different. Those tagged 32-bit pointers were used directly, but truncated by the width of the actual physical interface so they never touched the outside world.
...until Motorola released CPUs with full 32-bit address pins on the package. Oops.
Apple dropped support for 32-bit applications. That's different from requiring 64-bit applications to stop abusing unused address bits—something that hasn't ever been commonplace for x86-64.
x86-64 actually requires that every memory access occur with a "canonical" address, specifically to ensure that everything will be "64-bit clean". That is, even though virtual address space in some cases may be limited to 48 or 56 bits the actual address has to be sign-extended to 64 bits, so everything is "clean".
"Abusing" unused address bits is then just a matter of ensuring that any virtual addresses you use are restricted to the appropriate range. "x32" binaries do this in order to ensure that any pointers will fit within 32 bits even on x86-64, for example.
It's also possible to use a few low address bits for non-address information if you're willing to accept coarser alignment on all pointers. It's not as easy since you have to mask off those lower bits before dereferencing, as opposed to simply relying on the MMU to ignore high bits you're using for tags or whatever.
This was an interesting year for S-100, and it's reflected in the ads. The writing was on the wall for the S-100 bus on microcomputers (the PC platform was displacing it), so they were pivoting to the high-end (look at the S-100 SBCs designed to be used in larger installations, the way that VME would eventually be used). There's a good mix of ads for both applications in this issue. The standard was eventually retired 10 years later.
Ah, what days those were! Expecting the 68020 to be twice as fast as the 68000 at the same clock speed? Wow. Today we get table scraps of improvement. (On the other hand, the baseline is much higher now...)
Interesting to read about the NS32k. The only thing I ever heard it used was the Ceres workstation of the ETH Zurich, the native platform of Wirth's Oberon OS.
Jack Tramiel's Atari Corp. evaluated the NS32k series for use in their Atari ST. They even built a prototype. But the processor had bugs and quality issues and they went with the 68k instead. I understand NS did fix their issues but by then it was too late and it never caught on outside of anything but embedded applications (apparently used in laser printers...)
The Zilog z80000 wasn't introduced until 1986, but was pipelined and was in some respects about 6 years ahead of Intel. Apparently they are still used today in embedded application, though there was one moderately successful machine based on them back in the day.
I still have one of the original Apollo/Domain (DN300?) motherboards. It has two Motorola MC68000L8 chips on it. It was explained to me that Apollo found they needed both of them to make virtual memory work. 32 bit data width, 16 bit data bus.
Basically, the original 68000 isn't capable of atomically restarting an instruction interrupted during a memory access cycle, and so there's no way to implement a standard MMU.
So Apollo just chucked in a slave CPU that would detect the interruption of the master CPU, halt it, deal with any remapping or what have you, and then just completely reset the master CPU.
Also worth noting that this was solved in 68010 by changing the exception stack frame.
On that regard, it's a shame the Amiga released (1985) with a 68000 cpu. Particularly, move from SR became privileged 010+ and thus caused problems when Amiga finally moved past 68000. Those could have been easily avoided by releasing Amiga on 68010 to begin with, which is also a CPU with slightly higher IPC.
They compounded the issue by using 68000 again on A500/A2000 (1987), for negligible savings.
Of course, this does pale next to the gross mismanagement Commodore did of the Amiga thereon, which ultimately led to Commodore's own demise.
Honestly, byte order didn't matter much. There were so many more dimensions of incompatibility available that byte-order didn't enter the picture when you were choosing a processor for a product. Most data was exchanged via files written to floppy disks, and you just wrote conversion utilities (or programs dealt with save formats on the fly).
Most interesting sentence: "Currently, it is not likely that such techniques would be used for domestic surveillance."
[0] - https://archive.org/details/byte-magazine-1984-01/page/n213