61–70 of 180 posts
I forgot how powerful the i960 was - and how this demonstrated that despite that - that compatibility was king.
Earlier quoted context omitted.
Yeah but that was only made possible by Apple's unique circumstances: their close control over the entire tech stack, their experience with architecture transitions (PPC->x86-32->x86-64->ARM) and the required tooling (Rosetta, fat binaries, compilers), their relatively small market size, their expertise in developing with/for ARM from iOS, and enough cash in hand to buy out the entire fab capacity of TSMC. In the Win…
You're wrong about Microsoft here. They too have loads of experience developing their SW for multiple architectures, even moreso than Apple. Windows NT shipped on about 7 or so architectures including PowerPC for the Xbox360. And they also have experience with emulation, that's how they got Xbox 360 emulation on the newer X86 models. Just read their papers on arch emulation. What they don't have and Apple has is 10+…
I was one of the early adopters of Windows on ARM, the Windows 10 native port to ARM64 (ARMv8). At release, practically the only native development tool was WinDbg -- neither Visual Studio nor Windows Performance Analyzer had been ported. You could install Visual Studio in x86 emulation mode but it wouldn't run reliably as the toolchain would keep throwing heap errors, so cross-compilation was required and debugging was harder. There was basically zero information about what was and wasn't supported -- you'd just start porting and run into something like there being no OpenGL acceleration support. Or even more fun, that there was no ARM64 version of the Visual C++ Redistributable published, so you couldn't distribute a program that was dynamically linked to the CRT -- and the Visual Studio support staff didn't even know what ARM64 was and pointed to the x64 redist. This didn't start getting ironed out until around three months after Windows on ARM machines had started shipping.
And assuming you got past these problems, Windows has no universal binary system, so it's your job to figure out how to properly get the right platform executable installed and launched without any support from the OS. This was really bad in the early days of x64, where XP would just say "invalid executable" when trying to launch a x64 program on x86; these days it displays a slightly less cryptic "Machine Type Mismatch" error dialog with no further help.
Microsoft is trying to fix these problems now, but they're years late and the amount of software available as native ARM64 is still very low. Oh, and they already dropped support for the early gen Snapdragon 835 and 850 devices in Windows 11, which means no x64 emulation or ARM64EC support, and an even tinier effective market. In contrast, Apple managed the ARM transition much, much better -- they had native tooling, documentation, and development systems lined up in advance and a much more polished user experience on day one.
Earlier quoted context omitted.
Yeah but that was only made possible by Apple's unique circumstances: their close control over the entire tech stack, their experience with architecture transitions (PPC->x86-32->x86-64->ARM) and the required tooling (Rosetta, fat binaries, compilers), their relatively small market size, their expertise in developing with/for ARM from iOS, and enough cash in hand to buy out the entire fab capacity of TSMC. In the Win…
> These things are and will be toys . Heh, https://cdixon.org/2010/01/03/the-next-big-thing-will-start-... «The reason big new things sneak by incumbents is that the next big thing always starts out being dismissed as a “toy.” This is one of the main insights of Clay Christensen’s “disruptive technology” theory.» Tho Raspberry Pi computers are designed to a low price point, so they are aiming for the low end not the…
Earlier quoted context omitted.
Thats an interesting alternative history thought experiment. I wonder how early one could capture the complexity of the full PDP-11 microarchitecture on a single chip? Would it have been affordable? What about the support hardware?
Hmm – the smallest, most highly-integrated PDP-11 (-compatible) package ever made was the QFP 1806VM2, with around ~135k transistors; it integrated MMU, UART, parallel interface, keyboard controller, etc, but did floating-point instructions in interpretive microcode. I think that same transistor count was reached by Motorola on the 68020, which would've been around 1984, but would have needed the peripheral controlle…
(If I recall correctly, it wasn't until the 486 that the FPU was incorporated.)
So, what this article fails to really clarify is that the segment registers were now basically "selector" indexes into tables with base+length (in either pages or bytes) fields, execution permission controls. And these selectors and the GDT/LDT/IDT/TSS/call gates/task gates/etc were all designed to support OSs with a 4 level permissions hierarchy, user/library/driver/kernel (or similar), passing around access selectors which could do things like enforce the size of data structures, etc. And to support this, they added FS/GS so that all the general purpose registers could have their own permissions masks.
Pause for a moment and consider that again, Pointers (capabilities, aka selectors) can have not only a base address, but a hardware enforced limit, along with a permissions model that means a function like strcpy() would be incapable of writing to any memory that wasn't the target buffer or part of its own scratch space. Languages/os's could have enforced that called functions were unable to write to the callers stack, or even possibly run in their own completely separate stack. And that is just the beginning.
So, here nearly 40 years later the industry is still trying to recover from the mistakes of designing OS's and programming languages around flat memory models and simplistic user/supervisor permissions models. The 386 provided hardware assistance for writing OS's features that to this day aren't common.
ex: see CHERI.
I think the 80386's final design benefitted tremendously from the Motorola 68000, then the m68020. Had Motorola not released a proper 32 bit CPU without compromises, it could be argued that Intel would've had yet another stop-gap after the 80286, which itself wasn't intended to be a proper successor to the 8086/8088. As it is, the 80386 came with a number of compromises. For instance, there was no cache at all beyond…
It was a 386 that Linus Torvalds wrote the first Linux kernel on, and support for the new features of the 386 from the start was one of the reasons Linux took off instantly.
"It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386"
Nice write-up. Re-reading about the evolution and complexity of x86 makes me wonder about attempts to modernize x86. Does anyone know how Intel’s x86-S proposal to do a cleaned-up 64-bit architecture has been received? I looked for updates in the media but haven’t been able to find anything.