https://en.wikipedia.org/wiki/Intel_iAPX_432
Although some others had better luck and managed to survive for a while,
https://en.wikipedia.org/wiki/Burroughs_large_systems
https://en.wikipedia.org/wiki/Lisp_machine
https://en.wikipedia.org/wiki/Interlisp
https://en.wikipedia.org/wiki/Xerox_Alto
https://www.digibarn.com/collections/papers/dick-sweet/xdepa...
Among a couple of other ones.
Many architectures had each word loaded into a register, and you never had direct access to the memory. Those were absolute nightmares by today's standards.
On Intel hardware, we had different registers for memory access. I can't remember all of them now, but they were split between the code, data and stack. At some point we ended up with two different memory models, protected and real mode. This was the biggest PIA ever. We had MS/DOS in one mode, then Windows running in a different mode.
OS/2 came along, and we had a flat address space. What a novel concept. Windows NT next, and we were off, except for the addressable memory limit, which Intel resolved in one of the generations. DEC had a flat address space for almost 20 years, why was it so hard for everyone else? Legacy software.
On the Amiga, which I absolutely loved, had two memory spaces. One was called FAST RAM, and the other CHIP RAM. This was a decision by Jay Minor (may he RIP). I don't quite remember the reasoning at the time, but it had to do with the cost of memory, what was available, and what could be emulated. The last conversation I had with Jay was about Direct Memory Access (DMA). He said he wished he would have invented it. We had a bus mastering system on the Amiga, provided by Motorola, so devices could read and write directly to an address. This created other challenges, as we did not have any protected memory on the Amiga. If you program decided to overwrite memory of another program, or device, well, you had to meditate.
Children today are fortunate to be able to live in the land of purity. Flat address spaces, protected memory, distributed file systems. You missed the days of a sneaker net, having your hifi speaker erase your program, and the crunching, twinkle noise that came out of your floppy drive, and even hard drive if you were fortunate to have one.
So to what you said about SIMD, that literally has nothing to do with shit, and malloc/free. You're talking out your ass.
Been thinking about this for a while. Why don't instruction sets define arrays at the hardware level? That seems to be where practically all the pain of memory management comes from - dynamically sized arrays (and 2D arrays i.e. matrices) that grow or shrink throughout the program's lifecycle. Why aren't `malloc` and `free` architecture-level instructions? Let the hardware worry about finding space within memory, it'll almost certainly be faster than any software algorithm. And if you can do that, can't you putdynamically sized arrays into the architecture as well? This solves so many software related problems. x86 is CISC so it's not like they bother with instruction count; is there something I'm missing? Has this been tried before? I know SIMD is something similar, but I don't think anything exists that tries to replace malloc/free.