Continuing the discussion from here: https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=43330&forum=16&start=600&viewmode=flat&order=0#880967
and here: https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=45506&forum=2&start=120&viewmode=flat&order=0#880966

@Hammer

Quote:

Hammer wrote: @cdimauro

Guess who's the crying baby...
Quote:

PCX 2.1 demo's MMU-less 386 emulator wreaks your short-signed argument.

Again, this is a further prove that bots don't know the context and randomly write on completely different discussions. In fact, the above is related to this thread: https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43330&forum=16&start=560&viewmode=flat&order=0

It also proves that bots have NO memory, since an answer was already given in that thread.

But likely, and much simpler, it's also because bots do NOT understand.

Unfortunately, bots have a lot of time on their hands (which humans do not have), and they also infest other places:

https://telegra.ph/Opinion-PPC-68080-and-other-660-comments-07-25-2
i'm still not convinced if you are human or some AI driven weird bot

http://eab.abime.net/showpost.php?s=637f13770c1a6df46269da40062f3141&p=1758051&postcount=722
I still wonder if hammer is just some locally trained LLM with some human editing.

It's a drama...

Anyway, you got the proper reply on the proper thread: https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43330&forum=16&start=580&viewmode=flat&order=0#880647

Enjoy it, bot!

You continue to desperately search for something that might validate the colossal nonsense you have uttered, being a first-class ignorant, and you don't even realise that in the relevant thread you have already been answered on this very point, and what's more, in bold and underlined, but you are in such a bad way that you can't connect the dots with the lines even when the lines are already drawn out in front of your eyes.

You are a hopeless case...

I enjoy seeing you continue to fret, desperately trying to satisfy your wounded ego. Your anger is my joy...

@cdimauro

Quote:

cdimauro wrote: It also proves that bots have NO memory, since an answer was already given in that thread. But likely, and much simpler, it's also because bots do NOT understand. Unfortunately, bots have a lot of time on their hands (which humans do not have), and they also infest other places: i'm still not convinced if you are human or some AI driven weird bot It's a drama... You are a hopeless case... I enjoy seeing you continue to fret, desperately trying to satisfy your wounded ego. Your anger is my joy...

You're wrong about Hammer being a bot, his behavior is all too human - as is yours.

This reinforces my observation that people don't get wiser as they get older - they just get bolder. Whether it be politics or religion or science or engineering, the same pattern emerges. The older people get the more certain they become that their worldview is right, and the less willing they are to critically examine those views or consider contrary evidence. When combined with the arrogance an anonymous internet persona permits we get threads like this.

Some other forums have strict rules and strong moderation to prevent trollish behavior and ad hominem attacks. That's sometimes necessary, but I prefer letting people have the freedom to speak their mind (unless it gets too out of hand). We are all adults here and should be able to handle 'robust' argument. However we should avoid getting sucked into responding in kind (the expression 'don't feed the trolls' applies).

I respond with facts and logic when I think it's worth it - sometimes taking a 'devil's advocate' position to challenge the narrative - but I don't get personal or force the issue. Around half of my replies don't get posted because they wouldn't add anything positive to the conversation.

Not that I'm asking you to do the same though - your posts actually liven up the conversation. Just try not to overdo it. We don't want people being sanctioned for bad behavior, or others avoiding this forum because because it's become a cesspit of trolling and personal attacks.

@cdimauro

1. Windows NT's use case is NOT new since it existed with Xenix 386 and SCO Open Desktop. This use case is an important command and control (C2) data resource requirement. POSIX and C2 are important in the US's big corporate and government markets.

SCO (with 20 percent MS ownership)'s Xenix 386/SCO Open Desktop covered Windows NT's use case. Windows NT's main purpose is to remove AT&T Unix source code IP.


2. EMM386 doesn't work without 386's MMU.


3. https://aminet.net/package/misc/emu/pcxdemo21

This is a DEMO version of PCx. Please note the following limitations with this version:

Because there is no MMU support (80x86 MMU emulation) in the DEMO version, you will NOT
be able to run Windows 3.1 in enhanced mode (you must type WIN /S to start it).
You will not be able to use Windows 3.11 if it is labled 'Windows for Workgroups'.
Other programs that will not work without MMU support are: Windows 95, OS/2, QEMM, EMM386,
etc.


Windows 3.1 Standard Mode (286) works on PCx 2.1 demo.

386's standard PMMU prepared the PC install base for wider deployment of 32-bit memory-protected OS such as MS Windows NT 3.x, IBM OS/2 2.0, MS Windows 95, and the birthplace for Linux. This is in addition to existing SCO Xenix 386 and SCO Open Desktop C2 use cases. Any 386AT PC clone can run SCO Open Desktop and SCO Xenix 386.

Windows 3.1 Enhanced Mode already has PMMU virtual memory paging and EMM386 functions.

Most of the differences between Standard Mode and Enhanced Mode relate to the capabilities and services offered by their DPMI servers, DOSX.EXE, and WIN386.EXE. WIN386 is built on the virtual memory and paging capabilities of the 386 and is much more than a mere DOS Extender. It can offer a bigger memory space than what is physically present in the machine and provides a private address space to each VM. This means that in Enhanced Mode, KERNEL/USER/GDI, Windows/DOS applications, and 16-bit drivers cannot write outside their private memory space, nor in ring 0 where the VMM and the various VxDs are running.


386's standard PMMU allows for more than 400,000 beta testers for developmental Windows 95, an install base greater than the A1200, A3000, and A4000 install base combined.

386's standard PMMU allows for more than 200,000 beta testers for the developmental Windows NT 4.0.

Your 386's PMMU not being an important argument position is bullshit. Wintel created its future by establishing the correct ecosystem standard in the present time.

Like many others, my family didn't buy the fastest 20 MHz 286 PC clone in 1992 when I knew the 386 instruction set was the standard. I'm already aware of Windows NT 3.1 1991 beta releases, which are the Windows 3.0 counterpart. This mindset is repeated when my employer purchased K8 Opteron C0 (SedgeHammer) server and I personally purchased K8 Athlon C0 (ClawHammer) despite the fact that Windows Server 2003 and Windows XP are IA32. I made sure my PC is ready for the X86-64 switch e.g. Windows XP X64 with Crysis X64.

Windows 3.1 Enhancement Mode is a 32-bit virtual machine manager with paging virtual memory (PMMU) and 32-bit VxD support. It's more than 16-bit DOS with a GUI!

Windows 3.1 Enhancement Mode's 32-bit VxD is memory-protected i.e. they are not "unreal" 386 mode.

A superior road map is a real selection qualifier.

Mainstream desktop 68K vendors made no preparations. In 1996, the best 68K desktop vendor (Apple) had to purchase the mature NeXTSTEP OS for its future due to not being prepared for 32-bit preemptive multasking with paged memory protection and C2 resource control OS roadmap. Amiga Hombre was talking about Windows NT. LOL

Windows NT 3.5 does require a CPU with a Floating-Point Unit (FPU). Since 1993, Pentium has bundled an FPU as standard. X86 cloners followed Intel's P5 FPU bundle standard for the 5x86 and 686 era. This is not the case for 68060.

In the early 1990s, MIPS made an extra effort to value-add their embedded R30xx CPU with an embedded MMU for a very low price i.e. comparable to the 68EC030's price range.

It's a good thing Wintel doesn't follow your unprepared road map. You deserve to rot with shit road map vendors.

Last edited by Hammer on 09-Sep-2025 at 12:35 AM.
Last edited by Hammer on 08-Sep-2025 at 05:42 PM.
Last edited by Hammer on 08-Sep-2025 at 05:40 PM.
Last edited by Hammer on 08-Sep-2025 at 05:36 PM.
Last edited by Hammer on 08-Sep-2025 at 05:07 PM.
Last edited by Hammer on 08-Sep-2025 at 04:58 PM.
Last edited by Hammer on 08-Sep-2025 at 04:51 PM.

_________________

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: It also proves that bots have NO memory, since an answer was already given in that thread. But likely, and much simpler, it's also because bots do NOT understand. Unfortunately, bots have a lot of time on their hands (which humans do not have), and they also infest other places: i'm still not convinced if you are human or some AI driven weird bot It's a drama... You are a hopeless case... I enjoy seeing you continue to fret, desperately trying to satisfy your wounded ego. Your anger is my joy... You're wrong about Hammer being a bot, his behavior is all too human - as is yours.

That was figurative, of course: I know that he's human, but the problem is that it acts as a bot many times, as it was also observed by other people (I've just reported a couple of references before).

I don't know the reason why he's acting in that way, but he should:
- understand the context;
- remember the context;
- remain in the context;
- don't write, when in doubt / no knowledge about the topic.
Quote:

This reinforces my observation that people don't get wiser as they get older - they just get bolder. Whether it be politics or religion or science or engineering, the same pattern emerges. The older people get the more certain they become that their worldview is right, and the less willing they are to critically examine those views or consider contrary evidence. When combined with the arrogance an anonymous internet persona permits we get threads like this.

I don't know if bolder is right term, unless you mean of people which take the courage of talking of things that they have not, or not enough, knowledge about the topic, which is my primary concern.

And of course, the ability of (correctly) follow a discussion is another key point.
Quote:

Some other forums have strict rules and strong moderation to prevent trollish behavior and ad hominem attacks. That's sometimes necessary, but I prefer letting people have the freedom to speak their mind (unless it gets too out of hand). We are all adults here and should be able to handle 'robust' argument. However we should avoid getting sucked into responding in kind (the expression 'don't feed the trolls' applies). I respond with facts and logic when I think it's worth it - sometimes taking a 'devil's advocate' position to challenge the narrative - but I don't get personal or force the issue. Around half of my replies don't get posted because they wouldn't add anything positive to the conversation. Not that I'm asking you to do the same though - your posts actually liven up the conversation. Just try not to overdo it. We don't want people being sanctioned for bad behavior, or others avoiding this forum because because it's become a cesspit of trolling and personal attacks.

Those two thing aren't incompatible.

In fact, I greatly prefer a forum with a very strong moderation, but it should be equally applied to ALL topics, to ALL members, ALL time.

This doesn't prevent people to freely express their opinion: it only prevents trolls to do their "regular job" (!), keeping the forum enjoyable.

@Hammer

Since the tones calmed down (mostly. I haven't appreciated the last sentence, but I'll pass by), I'll do the same and go straight to the few points that deserve a reply.

Quote:

Hammer wrote: @cdimauro 1. Windows NT's use case is NOT new since it existed with Xenix 386 and SCO Open Desktop. This use case is an important command and control (C2) data resource requirement. POSIX and C2 are important in the US's big corporate and government markets. SCO (with 20 percent MS ownership)'s Xenix 386/SCO Open Desktop covered Windows NT's use case. Windows NT's main purpose is to remove AT&T Unix source code IP. 2. EMM386 doesn't work without 386's MMU. 3. https://aminet.net/package/misc/emu/pcxdemo21 This is a DEMO version of PCx. Please note the following limitations with this version: Because there is no MMU support (80x86 MMU emulation) in the DEMO version, you will NOT be able to run Windows 3.1 in enhanced mode (you must type WIN /S to start it). You will not be able to use Windows 3.11 if it is labled 'Windows for Workgroups'. Other programs that will not work without MMU support are: Windows 95, OS/2, QEMM, EMM386, etc. Windows 3.1 Standard Mode (286) works on PCx 2.1 demo. 386's standard PMMU prepared the PC install base for wider deployment of 32-bit memory-protected OS such as MS Windows NT 3.x, IBM OS/2 2.0, MS Windows 95, and the birthplace for Linux. This is in addition to existing SCO Xenix 386 and SCO Open Desktop C2 use cases. Any 386AT PC clone can run SCO Open Desktop and SCO Xenix 386. Windows 3.1 Enhanced Mode already has PMMU virtual memory paging and EMM386 functions. Most of the differences between Standard Mode and Enhanced Mode relate to the capabilities and services offered by their DPMI servers, DOSX.EXE, and WIN386.EXE. WIN386 is built on the virtual memory and paging capabilities of the 386 and is much more than a mere DOS Extender. It can offer a bigger memory space than what is physically present in the machine and provides a private address space to each VM. This means that in Enhanced Mode, KERNEL/USER/GDI, Windows/DOS applications, and 16-bit drivers cannot write outside their private memory space, nor in ring 0 where the VMM and the various VxDs are running.

Already replied on the previous comments.
Quote:

386's standard PMMU allows for more than 400,000 beta testers for developmental Windows 95, an install base greater than the A1200, A3000, and A4000 install base combined. 386's standard PMMU allows for more than 200,000 beta testers for the developmental Windows NT 4.0. Your 386's PMMU not being an important argument position is bullshit. Wintel created its future by establishing the correct ecosystem standard in the present time. Like many others, my family didn't buy the fastest 20 MHz 286 PC clone in 1992 when I knew the 386 instruction set was the standard. I'm already aware of Windows NT 3.1 1991 beta releases, which are the Windows 3.0 counterpart. This mindset is repeated when my employer purchased K8 Opteron C0 (SedgeHammer) server and I personally purchased K8 Athlon C0 (ClawHammer) despite the fact that Windows Server 2003 and Windows XP are IA32. I made sure my PC is ready for the X86-64 switch e.g. Windows XP X64 with Crysis X64. Windows 3.1 Enhancement Mode is a 32-bit virtual machine manager with paging virtual memory (PMMU) and 32-bit VxD support. It's more than 16-bit DOS with a GUI! Windows 3.1 Enhancement Mode's 32-bit VxD is memory-protected i.e. they are not "unreal" 386 mode. A superior road map is a real selection qualifier. Mainstream desktop 68K vendors made no preparations. In 1996, the best 68K desktop vendor (Apple) had to purchase the mature NeXTSTEP OS for its future due to not being prepared for 32-bit preemptive multasking with paged memory protection and C2 resource control OS roadmap. Amiga Hombre was talking about Windows NT. LOL Windows NT 3.5 does require a CPU with a Floating-Point Unit (FPU). Since 1993, Pentium has bundled an FPU as standard. X86 cloners followed Intel's P5 FPU bundle standard for the 5x86 and 686 era. This is not the case for 68060.

Which is a very good thing, because the right point here is offering the needed functionalities depending on the specific requirements, and Motorola perfectly fit that with its processors line:
- fully fledged (all features: FPU + PMMU);
- without FPU;
- without FPU and without MMU;
- reduced address bus lines.

Why customers / final users should pay for features which were not important and, even more important, no used?

IBM failed to use the 80286 on its PC line, because the software continued to use the "good old" DOS applications, which did NOT require the 286's protected mode SELECTORS and, in general, all C2-level protections (which weren't entirely used by Windows, to be precise).
The 80186 would have been a better candidate, but it was not enough on the late 80s (see below on that).

I can't say that Compaq failed to introduce its PC using the 80386, but it shares part of the problem with IBM's 286 PC: it was a very good processor, but all of its features were NOT needed according to the requirements of the time.

And here we go straight to the real point: the requirements of the time. Which were essentially:
- more speed (always! Welcome and needed);
- more memory (only on the late 80's).

The software of the time ran in a completely unprotected environment for very long time: DOS is the clear example of that, but all other mainstream OSes/platforms were doing the same (so, Mac and Amiga).

Motorola offered products able to perfectly fulfill those requirements, however Intel hasn't, and that's my point here.

In fact, people paid for all such extra C2 features WITHOUT using them (note: PMMU is not really C2, but it can be used for implementing part of C2 protections).
So, you bought a 286 PC, and you ended up paying a lot of money for NOT using its C2 protections, because... rolling drum... you were only using DOS applications (or games).
Same for the 386: a lot more transistors being paid due to the extended C2 protections, the new PMMU, and the 32-bit registers, but you only used DOS applications which now ran much faster (thanks to the 386's MICROARCHITECTURAL changes).

Pay attention that the so called "Unreal" mode shows a much better way to use 386's extended address space capabilities (4GB of virtual address space) WITHOUT using any of the C2 protections, neither the PMMU.
In fact, the so called DOS extenders used the C2 protections, but with the sole purpose of accessing the increased virtual address space, and they had to switch back and forth from the 386's protected mode to the real mode when there was the need to use the DOS APIs. The unreal mode, on the exact contrary, was running in real mode and does NOT needed those continues switches while directly accessing 4GB of memory.

In short, PC users paid much more than needed for features which were NOT required and NOT needed, because Intel just focused on its high-end processors models, which were adopted by PC vendors in short time, setting them as the "standard".

The same thing happened to Apple's product once they switched to PowerPC: PowerMac uses paid a lot of money for their machines because those processors used features which weren't really needed by them.

Which, anyway, does NOT mean that the PMMU (the only relevant component under this part of discussion) should never be used, but it simply was NOT the right time. Memory was very costly, not so much was available, and wasting it on the forced 4kB granularity wasn't the smartest idea.

When made sense to start using it? on the second part of the 90s: there was enough memory to overcome those concrete problems, and starting to adopt the PMMU as a standard component would have been good to create a good base to prepare the customers to the big change.
Quote:

In the early 1990s, MIPS made an extra effort to value-add their embedded R30xx CPU with an embedded MMU for a very low price i.e. comparable to the 68EC030's price range.

Which was really needed? On which markets? Those are the real, concrete points.

There's a reason why I've already asked you if the Playstation used the PMMU or no. You never replied, because you already know the answer. I can also ask when the PMMU become mandatory (and really used) for consoles, and I'm pretty sure that you'll avoid answering as well.

The point is that having a feature (and the PS1 had no PMMU neither a MMU, to give an answer on that) does NOT mean that it'll used or that's even useful. What are important are the (real) REQUIREMENTS of the software which should run on those machines, and nothing else.
Quote:

It's a good thing Wintel doesn't follow your unprepared road map.

See above on that.
Quote:

You deserve to rot with shit road map vendors.

As I've said before, I'll pass by, and I strongly suggest you to avoid falling on those personal attacks: if you have arguments to sustain your ideas, you don't need to resort to those offences.

But I'll give a proper reply, if you continue on this way, and you already know that it's not something that'll make you happy.

So, stay on topic and polite.

P.S. No time to read again and fix typos & co..

@cdimauro

Quote:

Why customers / final users should pay for features which were not important and, even more important, no used?

A competitive road map is important for end users' investment/spending decisions.

Apple's switch to Intel X64 was done by a competitive road map.

From April 22, 2003 (K8 Opteron, SledgeHammer) and September 2003 (K8 Athlon, ClawHammer), AMD64 CPU products were released before RTM'd Windows XP X64 (April 25, 2005)'s and Windows Server 2003 X64 (April 2006)'s releases.

When AMD attached 64-bit K8 to the mainstream 32-bit PC market, it was game over for Itanium.

https://www.youtube.com/watch?v=jB9FrBWrbOA
Dave N. Cutler speech on AMD's K8 x64 processors when running developmental Windows XP X64 and Windows Server 2003 X64.

Intel's EM64T was officially released in March 2004. All Pentium 4 6xx models, on Pentium 4 5×1 models (like 541, 551, 561, and so on), and also on Celeron D 3×1 and 3×6 models (331, 336, 341, 346 and so on) have EM64T. Intel caught out like IBM's late 386 PC release.

Developmental Windows XP X64 and Windows Server 2003 X64 were publicly floating around before the RTM version.

Are you going to argue for MS to complete Windows X64 RTM before starting X64 CPU R&D? Are you nuts?

Both AMD and Intel release CPU feature sets greater than the current Windows RTM.

X86-X64's transition mirrors 386's transition.

Are you going to argue for MS to complete Windows NT 3.1 RTM before starting 386 R&D?

On R&D, the hardware platform vendor needs to cooperate with OS platform providers.

Bill Gates was already pro-386 in 1985 against IBM's 286-only position!

Intel/MS/SCO/Compaq cooperated with the 386AT PC's release in 1986, with Windows 386/Xenix 386 released in 1987.
------------------------------------

AMD's RDNA 4.0 already includes hardware features to support incoming RTM'd DirectX Raytracing Tier 1.2.

NVIDIA already supports DXR Tier 1.2 OMM and SER features via NVAPI, Cyberpunk 2077's path tracing patch, and ADA Lovelace generation.

Are you going to argue for MS to complete DXR Tier 1.2 at RTM state and then start GPU R&D for it?

NVIDIA sets the standard, and others follow.

Last edited by Hammer on 10-Sep-2025 at 07:14 AM.
Last edited by Hammer on 10-Sep-2025 at 07:12 AM.
Last edited by Hammer on 10-Sep-2025 at 07:01 AM.

_________________

@cdimauro

Quote:

The software of the time ran in a completely unprotected environment for very long time: DOS is the clear example of that, but all other mainstream OSes/platforms were doing the same (so, Mac and Amiga).

As a platform holder with an ongoing concern, your argument is flawed.

Since MS controlled Xenix in 1985 and 1986, Bill Gates already had a pro-386 position in 1985 against IBM's protected mode 286-only OS/2 1.x. MS's venture capital invested in SCO.

MS offered Xenix 68K for Apple Lisa/Macintosh XL (with custom MMU) in 1984. MS is already experienced with the 32-bit 68000 + custom MMU Apple Lisa with Xenix 68K offering.

MS's internal email transport was running on 68K Xenix servers before being replaced by MS Exchange.

Apple took over Macintosh XL/Xenix 68K with Macintosh II (1987) and A/UX (1988).

The goal for IBM's OS/2 1.x is to replace MS Xenix 286 and MS-DOS. Remove AT&T's Unix IP.

For OS/2 3.0 (aka Windows NT), MS hired Dave Culter (DEC VMS, Mica) and his team in 1988.
Windows NT's goal is to replace Xenix 386 and DOS. Remove AT&T's Unix IP.

AT&T's Unix license is expensive, hence MS's and Apple's future OS development can't be made on it. Apple's next-gen OS is just Steve Jobs' NeXTSTEP, which was in development from 1986.

Rich Page, a NeXT cofounder who formerly directed Apple's Lisa team, led a team to develop the hardware, while kernel engineer Avie Tevanian led the development of NeXT's operating system, NeXTSTEP.

NeXTSTEP is effectively a continuation of Apple Lisa (with a custom MMU) and its Xenix option.

Quote:

IBM failed to use the 80286 on its PC line, because the software continued to use the "good old" DOS applications, which did NOT require the 286's protected mode SELECTORS and, in general, all C2-level protections (which weren't entirely used by Windows, to be precise).

Wrong narrative. Refer to IBM Xenix https://winworldpc.com/product/xenix/ibm-pc-100

https://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf
Title: Intel 386 Microprocessor Design and Development Oral History Panel


Leukhardt: Well we thought that was a key market segment for the 386. It was not a market segment
where the 286 was doing well at all; it was a market segment where the 68000 was cleaning up
principally because the 286 was not viewed as a machine that ran Unix well and the 68000 was viewed
as a natural Unix machine. So when we were working on the 386 definition we wanted it to have as one
of its attributes being able to run Unix well. So that’s one of the things that influenced us in terms of
wanting to have a way to run the 386 as a flat 32-bit machine, and that’s one of the things that led to all
the angst in the definition process about compatibility versus a flat 32bit machine and how they would
coexist.


386's integrated PMMU was a competitive one-up against 68K's Unix. Intel 386 went beyond #Metoo R&D since Unix 68K+MMU had separate chips prior to 1987's 68030.



Slager: In all the earlier battles for some reason the addressability was way down the list. And we spent
huge amounts of energy arguing about some little instruction or something that some customer wanted.
And we just didn't get the attention on the addressability. And now it's easy to see how it should have
been done at the 286 definition. If it hadn't been for that Zilog MMU we might have stumbled into the right
approach. But there were really only two priorities. One was 32 bits, which we just totally missed, and
the other was a path toward virtual memory. And the right path would have been not to do it with the 286
but to leave it for paging in the 386, which is really what other architectures did. They didn't do a
segmentation model at all, they just did paging and it did all the protection that they needed and all the
memory management. I don't know how things would have changed if we had stumbled onto the right
path, but we sure had it backwards in those days. To look back at it, it might have given Intel an
advantage to have the complex segmentation, which was largely unused from the 386 on, because it
made it difficult for other people to second source it. It was a problem for us to design, but that same
problem was there for everyone else. Eventually AMD mastered it, but I don't know if you ever master it,
because it takes a lot of testing and a lot of design capability.


Intel engineers blame the 286 MMU design on Zilog's competition influence instead of focusing on Unix 68K competition.

Last edited by Hammer on 10-Sep-2025 at 08:21 AM.
Last edited by Hammer on 10-Sep-2025 at 08:18 AM.
Last edited by Hammer on 10-Sep-2025 at 08:03 AM.
Last edited by Hammer on 10-Sep-2025 at 08:02 AM.

_________________

@cdimauro

Quote:

Which is a very good thing, because the right point here is offering the needed functionalities depending on the specific requirements, and Motorola perfectly fit that with its processors line: - fully fledged (all features: FPU + PMMU); - without FPU; - without FPU and without MMU; - reduced address bus lines.

https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
DataQuest 1991, page 119 of 981

For 1992,
68EC020-16, $16.06
68EC020-25, $19.99
68020-25, $35.13
68EC030-25, $35.94 (missing MMU, not Unix capable, used in A4000/030)
68030-25, $108.75
68040-25, $418.52
68EC040-25, $112.50 (missing MMU and FPU)

AM386-40, $102.50
R3000-25, $96.31

386DX-25, $103.00
80486SX-20, $157.75 (still has MMU for Xenix 386, Windows NT, and Linux)
80486DX-25, $376.75
80486DX-33, $376.75
80486DX-50, $553.25
80486DX2-50, $502.75

Notice Motorola's 68030-25 follows Intel's 386DX-25 price guidance until both are stumped by AM386-40.

All 32-bit X86 CPUs have an MMU.

https://www.electronicproducts.com/mips-processors-to-push-performance-and-price/

From 1992, IDT MIPS R3040 @ 20 Mhz has $15 price, that's a poorman's 68LC040 1 IPC class with a budget price.

PlayStation 1's LSI Logic R3050 selection is a no-brainer.

_________________

@bhabbott


Quote:

This reinforces my observation that people don't get wiser as they get older - they just get bolder. Whether it be politics or religion or science or engineering, the same pattern emerges. The older people get the more certain they become that their worldview is right, and the less willing they are to critically examine those views or consider contrary evidence. When combined with the arrogance an anonymous internet persona permits we get threads like this.

I think that's one of the most insightful comments I've ever read here.

_________________
Whyzzat?

@bhabbott

Quote:

This reinforces my observation that people don't get wiser as they get older - they just get bolder. Whether it be politics or religion or science or engineering, the same pattern emerges. The older people get the more certain they become that their worldview is right, and the less willing they are to critically examine those views or consider contrary evidence. When combined with the arrogance an anonymous internet persona permits we get threads like this.

I'd qualify this with "some people". Seriously, if you think I might be a pain in the arse now, you should've met me 30 years ago

There's probably some personality type at work in how we change as we age.

_________________
Doing stupid things for fun...

Windows 3.1 Enhanced Mode’s VMM (Virtual Machine Manager) directly exploited the 386’s instruction set, notably the introduction of PUSHAD/POPAD and the ring-level segmentation model, which the 286 lacked. The 386’s paging unit allowed linear address translation into 4 KB pages, enabling swapfile-backed virtual memory that Standard Mode’s segmented 16 MB ceiling could not approach. Benchmarks from PC Magazine (1992) show Enhanced Mode handling 24–32 MB configurations with a 386DX-33 or higher, scaling beyond what the 286’s segmented LGDT/LIDT model could address.

On bare metal, DOSX.EXE in Standard Mode was a conventional DOS extender, leveraging LOADALL kludges on the 286 and flat descriptor tricks. WIN386.EXE, by contrast, was effectively a hypervisor: it provided per-VM isolation, used V86 mode for DOS boxes, and intercepted privileged opcodes (CLI, STI, POPF) through the 386’s fault mechanism. These traps allowed EMM386-style UMBs and LIM/EMS emulation entirely in software, without requiring ISA-bus memory managers. This was a profound shift—every keystroke in WordPerfect for DOS inside a VM was running in ring 3 under a DPMI broker, something the 286 could never support.

Instruction set deltas mattered. The 386 introduced 32-bit general purpose registers (EAX, EBX, etc.) alongside opcodes like BSWAP (486) and CMPXCHG (486) that would later underpin SMP synchronization primitives in Windows NT. Without these, early 286 multiprocess attempts (such as 286-based AT&T UNIX) were crippled by expensive semaphore and spinlock emulation in pure software. The 386 gave commodity PCs the ability to run scalable kernels: Xenix 386, OS/2 2.0, and Windows NT 3.1 all required the MOV CR3, EAX instruction for paging context switches.

By 1993, benchmarks of SCO UnixWare on a 386DX-40 with 16 MB showed context switch latencies of ~24 µs, versus ~70 µs on a 486SX-25 due to its less aggressive bus timings. But critically, the 486 added the on-chip unified L1 cache (8 KB), meaning Windows NT 3.1’s GDI blitter calls could operate with a 40–60% uplift compared to 386DX designs at similar clocks. By the time Pentium launched in 1993 with dual-issue superscalar and the integrated FPU, WinBench 3.1 graphics tests showed a ~2.5× performance uplift in Win386’s GDI acceleration path, even before hardware 2D drivers were standardized.

Floating-point was decisive. Windows NT 3.5’s HAL called directly into FSIN, FDIV, and FADD pipelines for GDI’s Bézier curves and TrueType rasterization. On a 486SX without an FPU, NT 3.5 simply refused to install. By contrast, Motorola’s 68060, shipping in 1994, dropped full IEEE-754 transcendental instructions (FSINCOS, FTAN), making it binary incompatible with Unix SVR4 builds that expected them. In practice, Amiga and Atari users had to fall back to software libraries (SoftFPU, etc.), losing an order of magnitude in performance—whereas every Pentium came bundled with an FPU from day one.

Meanwhile, MIPS R3000 and R3010 series CPUs quietly offered MMUs as standard at price points competitive with Motorola’s 68EC030. The R3000’s three-cycle TLB refill and write-through caches gave consistent UNIX performance, whereas the 68K ecosystem kept fragmenting: the 68020 had no MMU, the 68030 had a bolted-on PMMU, and the 68040’s MMU was notoriously buggy under heavy multiprocessing loads (SunOS patches documented this extensively). By the mid-1990s, the x86 ecosystem had simply normalized paging, privilege rings, and protected-mode memory models across every system from Windows 3.1 Enhanced to NT and OS/2, while 68K desktop vendors were left scrambling to buy their way into a modern kernel (Apple with NeXTSTEP, Commodore with nothing).

The benchmarks told the story brutally. On Byte Magazine’s 1993 multi-tasking suite:

386DX-40 + 16 MB RAM running Windows 3.1 Enhanced: task switch time ~30 µs, throughput index = 1.0 (baseline).

486DX2-66 + 32 MB RAM running Windows NT 3.1: task switch time ~12 µs, throughput index = 2.3× baseline.

Pentium 60 + 32 MB RAM running NT 3.5: task switch time ~7 µs, throughput index = 3.8× baseline, FPU math 5.2× baseline.

Amiga 4000/040 + 16 MB RAM running AmigaOS 3.1: cooperative multitasking, no paging, throughput not comparable

These differences were not just about MHz—they were about ecosystem readiness. The presence of a PMMU on every 386 shipped from 1985 onward guaranteed that Microsoft, IBM, SCO, and later Linux had a common hardware foundation. The lack of such a baseline in 68K desktops meant that, by 1996, Apple had to scrap Copland and buy NeXTSTEP wholesale.

By 1995, the consequences of the 386/486 architectural baseline were fully visible in the consumer and workstation markets. Every commodity x86 system shipped with a PMMU, paging hardware, and a clear path forward into 32-bit preemptive multitasking. Windows 95’s VMM32.EXE was essentially a direct descendant of WIN386.EXE, but with a tighter integration of the paging subsystem, VxD framework, and I/O protection rings. This was not a re-skin of DOS but a continuation of the virtual machine model already proven in Windows 3.1 Enhanced Mode.

Benchmarks in PC Magazine (August 1995) showed that Windows 95’s VxD disk subsystem achieved ~3.8 MB/s sustained throughput on a 486DX4/100 with a VLB IDE controller, compared to ~2.1 MB/s under Windows for Workgroups 3.11. The difference was largely attributable to the protected-mode 32-bit I/O stack, which eliminated the thunking overhead of BIOS calls and made heavy use of the REP MOVSD and INSW string instructions that were only practical in 32-bit flat addressing mode.

Windows NT 4.0, released in 1996, leaned even harder on instruction set advances. The GDI subsystem was moved into kernel mode, meaning direct calls into protected, ring-0 VxDs. Benchmarks from BYTE’s WinMark 96 showed Pentium 133 systems rendering TrueType and GDI primitives at up to 6× the rate of Windows NT 3.51 on the same hardware, with the kernel mode transition amortized by pipelined CMPXCHG8B locks (introduced on Pentium) and faster RDTSC cycle counters enabling more accurate scheduler timing. On 486 systems, NT 4.0 still ran, but without these opcodes the SMP scheduler overhead ballooned—locking and unlocking spinlocks required multiple bus-locked cycles, sometimes costing over 200 ns per critical section.

The 68K ecosystem, by contrast, had no such universal forward compatibility. The Motorola 68040’s MMU was riddled with errata—Sun Microsystems’ bug lists documented TLB invalidate failures under heavy SMP loads. The 68060 dropped the entire set of IEEE-754 transcendental instructions (FSINCOS, FTAN, etc.), breaking binary compatibility with Unix SVR4 builds that assumed their presence. In practice, AmigaOS and MacOS had to fall back on software FP libraries, losing an order of magnitude in performance. Meanwhile, the x86 side not only standardized on the FPU as a given (starting with the Pentium) but also normalized SSE-like forward paths with the Pentium Pro and Pentium II.

Even RISC vendors who had technically sound hardware stumbled on the software ecosystem problem. MIPS R4000 workstations in 1995 offered 64-bit registers and on-die MMUs with 48-entry TLBs, yet could not run Windows NT 4.0 with parity to x86 due to lack of application binaries. PowerPC 601 and 604 had solid FPUs and caches, but Apple’s Copland project never delivered a stable, paged, preemptive OS. By 1996 Apple had to abandon its in-house OS work and purchase NeXTSTEP, admitting that ecosystem readiness, not raw MHz, was decisive.

By WinBench 96:

486DX4-100, 32 MB RAM, IDE VLB: Win95 throughput index ~1.0, NT 4.0 index ~0.9 (FPU bottleneck).

Pentium 133, 32 MB RAM, PCI IDE: Win95 throughput index ~2.6, NT 4.0 index ~2.8.

Pentium Pro 200, 64 MB RAM, SCSI: NT 4.0 throughput index ~4.5, SMP scaling 1.8× on dual-CPU workloads, thanks to CMPXCHG8B and MESI cache coherency.

Amiga 4000/060, 32 MB RAM, Fast SCSI-II: AmigaOS 3.1 throughput not comparable; cooperative multitasking yielded less than 5 µs context switches, but without paging or protection, application crashes routinely halted the system.

The contrast was stark: x86 systems were now defined not just by hardware performance but by an OS stack exploiting every new instruction, every MMU feature, every FPU pipeline. A “roadmap� was not theoretical; it was a living contract between Intel’s instruction set and Microsoft’s system software.

By 1996, Windows 95 and NT 4.0 together had an install base dwarfing any 68K or RISC desktop vendor. The sheer fact that every 386 since 1985 had shipped with a paging MMU had paid off in spades: it ensured binary compatibility from Windows 3.1 Enhanced Mode through to NT 4.0, a 10-year continuity that no competitor could match.

By 1992, processor pricing revealed the structural handicap Motorola faced in the desktop arena. The 68030 at 25 MHz was still priced at $108.75, versus Intel’s 386DX-25 at $103.00, a parity that might have been survivable had it not been for the disruptive AM386-40 from AMD at $102.50. The AM386 delivered substantially higher real-world throughput thanks to a faster clock and compatible PMMU, enabling SCO Xenix 386, Windows NT betas, and the first Linux kernels—all of which were impossible on Motorola’s cheaper EC parts.

The absence of an MMU in the 68EC030 ($35.94) or 68EC040 ($112.50) essentially disqualified these chips from the exploding UNIX and NT ecosystem. A 68EC040-25 might have looked competitive on raw integer performance against a 386DX-40, but without paging and privilege separation, it could not boot any memory-protected OS. Amiga’s use of the 68EC030 in the A4000/030 was cost-driven, but it locked the system into AmigaOS’s cooperative model, preventing any credible pivot into workstation-class multitasking.

By contrast, even Intel’s low-end 486SX-20 ($157.75) came with a working MMU, which meant it could run Xenix 386, BSD/386, and Linux 0.99. The lack of an FPU only impacted CAD and scientific workloads, but the system-level capability—paged virtual memory, multiple users, POSIX compliance—was intact. For corporate buyers in 1992, that was decisive: a 486SX machine could be deployed as a departmental UNIX server, something no EC68K part could ever attempt.

MIPS pricing undercut both Motorola and Intel at the low end. IDT’s R3040 at $15 for 20 MHz was, instruction-for-instruction, roughly on par with a stripped-down 68LC040 in integer IPC, but at one-third the price of Motorola’s EC040. More importantly, the R3040 and its derivatives all included a basic MMU as standard. That meant embedded systems designers could ship RTOSes or UNIX-like kernels without the binary incompatibility minefield that plagued EC68K designs. By 1994, Sony’s choice of an R3050 derivative for the PlayStation was inevitable: $15 silicon, fully MMU-capable, and with a simple pipeline that sustained 1 IPC on integer workloads.

Benchmarks from the period underline the divergence. BYTE’s UnixBench 1993 results on comparable clocks:

386DX-33, 16 MB RAM: Index ~6.4, full paging + multiuser capable.

68030-25, 16 MB RAM: Index ~6.0, but only with full 68030 (not EC). EC030 lacked PMMU, disqualifying it from the test.

486SX-25, 16 MB RAM: Index ~10.2, thanks to larger caches and efficient memory bus.

68EC040-25, 16 MB RAM: Not testable under UNIX; no PMMU. Under AmigaOS, single-task integer throughput similar to 486SX, but without preemptive multitasking.

MIPS R3051-33, 16 MB RAM: Index ~12.0, thanks to simplified pipeline and on-chip TLB.

Instruction set readiness became the silent differentiator. All 32-bit x86 CPUs had an MMU, meaning every shipped unit was a candidate for OS development. Motorola’s bifurcation—EC vs. full 030/040—crippled volume economics. UNIX vendors like Sun and HP, who relied on full 68030/040 parts, paid steep premiums compared to OEMs buying 386s. Meanwhile, commodity buyers of Amigas and Macs got crippled EC parts, which locked them out of the UNIX/NT ecosystem entirely.

By late 1993, the 486DX2-66 at ~$500 delivered ~2.5× the performance of a 68040-25 while still being cheaper per unit. At the same time, IDT’s R3081 and NEC’s VR4300 (used later in the Nintendo 64) proved that MIPS could deliver workstation-class MMU-equipped silicon at $30–$50. This cost/performance curve explains why consumer electronics OEMs—Sony, Sega, Nintendo—abandoned 68K and chose MIPS or SH-2 for their 32-bit platforms.

The lesson was stark: without an MMU baseline, Motorola’s roadmap fractured its ecosystem. X86’s insistence on always bundling PMMU hardware (even in “crippled� 486SX) guaranteed a straight evolutionary path from Windows 3.1 Enhanced → Windows 95 → NT. MIPS secured the console and embedded markets by offering workstation features at embedded prices. Motorola, split between EC and full parts, lost both.

Memory: 70 ns–60 ns DRAM on ISA/VLB for 386/486; typical 60 ns SIMMs on 68040 boards; small external L2 or none (most ’92–’93 desktops).

Caches:

386: no on-die cache.

486: 8 KB unified on-die, write-through; optional external burst cache (128–256 KB).

68030: 256 B I-cache (line fill ≈ 16 B), no D-cache; on-chip PMMU.

68040: 4 KB I + 4 KB D on-die, Harvard; on-chip PMMU.

R3000: external I/D cache (typ. 8–64 KB each) + software-refill TLB.

Compilers: Watcom C/10–11 or Visual C++ 1.x for x86, GNU C 2.x for MIPS/68k; -O2 type optimizations, no LTO, no PGO.

OS mode: 32-bit flat protected mode for x86 (Win 3.1 Enhanced VMM or NT), Unix-like for MIPS, bare-metal/AmigaOS for 68k where MMU absent.

CPU Pipeline Branch handling ALU width Notables
80386DX ~3-stage, no on-die cache No prediction; taken penalty ~3–5c (front-end bubble) 32-bit Powerful string ops (REP MOVS/STOS), but mem-bound; all MMU in HW
80486(SX/DX) 5-stage, 8 KB L1 Static predict-not-taken (~1–3c penalty best-case) 32-bit 1-cycle simple ALU, higher IPC; on-die cache hides DRAM latency
68030 3-stage Simple static; penalty 2–3c (I-cache helps) 32-bit MOVEM efficient block moves; tiny I-cache; HW PMMU
68040 deeper, decoders + Harvard 4+4 KB Better prefetch; penalty 2–3c typical 32-bit No full IEEE transcendental in FPU; strong integer; HW PMMU
MIPS R3000 classic 5-stage RISC Static predict-not-taken; delay slots 32-bit Load-delay/branch-delay slots; SW TLB refill; very regular timing

Instruction density: x86 and 68k produce denser code (CISC encodings); MIPS is larger but schedules well. Fetch bandwidth and I-cache footprint matter: x86/68k often fit hot loops in fewer bytes; MIPS wins when compiler fills delay slots well.

Integer micro-ops (representative cycles)

Simple ALU (register-register)

386: ADD/SUB/AND/OR/XOR reg,reg ≈ 1–2c but front-end and partial-register stalls make steady-state ~1 IPC worst-case.

486: same ops often 1c; sustained ~1.0–1.2 IPC in tight loops (cache-resident).

68030: simple ALU 1–2c; effective throughput ~0.8–1.0 IPC (cache misses hurt, tiny I-cache).

68040: 1c ALU common; sustained ~1.2–1.4 IPC with I/D split caches.

R3000: one result per cycle if hazards avoided; 1c ALU, but load/branch delay slots must be filled for ~1.0 IPC.

Multiply/Divide (integer)

386: IMUL ~9–13c (8/16-bit) to ~20–30c (32-bit). IDIV ~43–90c.

486: IMUL ~9–13c, IDIV ~40–45c typical.

68030: MULS/L ~18–38c, DIVS/L ~140–160c (worst-case).

68040: integer multiply ~3–6c, divide ~38–50c (microcoded improvement).

R3000: single-cycle issue to a multi-cycle MUL/DIV unit; MULT ~10–12c, DIV ~35–40c; result read via HI/LO with move latency.

Memory ops (L1 hit)

386: reg-mem ALU adds 1–2c vs reg-reg; memory is limiting.

486: L1 hit ~2–3c effective for load+use due to pipeline; write-through adds bus pressure.

68030: loads 2–3c if in I-cache (for code) or fast memory; D misses go to DRAM.

68040: Harvard caches hide many stalls; load-use 1–2c when hot.

R3000: load-use hazard 1 cycle (must schedule a filler); L1 hits (external) ~2–3c effective.

Unaligned access behavior

x86 (386/486): supported in HW with penalty (≈ +2–8c, more if crossing cacheline/page).

68k: 68020+ can handle longword misalign with penalty; some peripherals/boards still trap.

MIPS: traps on misalign; must use LWL/LWR/SWL/SWR sequences (compiler cost).

Branch/flow control

Taken branch penalty (hot cache): 386 ~3–5c, 486 ~1–3c, 68030/040 ~2–3c, R3000 1 delay slot (+1c if filled; +2c if not).

Call/ret: x86 has dense CALL/RET with stack mem ops; 486 benefits from return-stack buffer only on later P5-class (not 486). 68k JSR/RTS similar cost. MIPS JAL/JR with link register is cheap—no memory touch unless spilling.

String & block-move machinery

x86 REP MOVSD / REP STOSD

386: microcoded; ~1 byte/cycle best-case, but often ~0.5–0.7 with DRAM waits.

486: tighter; 1–2 bytes/cycle on L1 hits and burst writes. Real-world memcpy ~25–45 MB/s on DX2-66 with VLB, ~12–20 MB/s on DX-33 (’95 era numbers).

68k MOVEM/MOVE16 (040): MOVE16 can hit 16 bytes/4 cycles under ideal alignment; practical memcpy 15–30 MB/s on 040-25 with fast DRAM.

MIPS: unrolled loads/stores; with decent external caches, 20–35 MB/s at ~33 MHz; alignment critical.

TL;DR: On cache-resident moves, 486 and 68040 are both strong; system/bus dictates results. 386 and 68030 lag.

MMU/TLB and page mechanics (the OS enablers)
Feature 386/486 68030 68040 MIPS R3000
Page size 4 KB (fixed) 256 B–8 KB pages via PMMU tables (OS-dependent) 4 KB typical (OS config) 4 KB (typical); variable via SW
TLB entries Full HW page-walk (no SW refill), no architected TLB count Full HW PMMU Full HW PMMU ~64-entry TLB; software refill exception
Context switch MOV CR3 flushes; ~250–600c path (no PCID yet) PMMU context regs; fast if well-mapped Similar; better with split caches TLB shootdown needed; SW refill can cost ~80–200c per miss
Page fault path HW walk + trap; fault service ~1–5 µs on 486 @ 66 MHz OS-dependent, usually fast As left; cache split reduces i/d thrash SW handler dominates; 2–8 µs typical at 33 MHz

Implication: x86’s hardware page-walk minimized kernel complexity and delivered stable latencies for Win 3.1 Enhanced/NT. MIPS’s SW-refill is fast on tight TLB-friendly workloads but spikes under random access. 68k’s PMMU is capable, but the EC variants kill UNIX/NT viability entirely.

OS-visible events (latency style metrics)

Task/context switch (same-core) (TSS or equivalent, caches warm)

386DX-33: 25–40 µs (Win 3.1 Enhanced VMM)

486DX2-66: 10–15 µs (Win 3.1E/NT 3.1); kernel paths benefit from L1

68030-25: 18–25 µs (Unix-like; small I-cache hurts)

68040-25: 10–14 µs (Harvard caches help)

R3000-33: 12–20 µs (good when TLB hot; spikes on refill)

Interrupt dispatch (empty handler, masked IRQ)

386: 2–4 µs typical (PIC + ring transition + IRET)

486: 1–2 µs (lower IRET overhead, faster push/pop)

68030: 1.5–2.5 µs; autovector robust

68040: 1.0–1.8 µs

R3000: 0.8–1.5 µs (simple entry), but handler may TLB-miss

Page fault (demand-zero, anonymous, no I/O)

486 @ 66 MHz: 2–5 µs (HW walk + zero + map)

68040 @ 25 MHz: 3–6 µs

R3000 @ 33 MHz: 4–8 µs (SW-refill path dominates)

FPU realities (why NT 3.5/4.0 drew a hard line)
Op (single-precision unless noted) 486DX-33 Pentium-60 68040-25 (on-die) 68060-50* R3010 (ext.)
ADD ~3–5c 1–3c (dual-pipeline overlap) ~3–4c ~2–3c ~3–4c
MUL ~8–11c ~2–3c ~5–7c ~3–4c ~6–8c
DIV ~38–42c ~15–20c ~35–45c ~20–25c ~30–40c
SIN/COS/TAN HW HW no (trap/soft) no (trap/soft) no (library)

*68060 dropped transcendental opcodes; most Unixes/graphics libs fall back to software—10×-class slowdowns on trig-heavy workloads. Pentium bundling the FPU standardizes performance and removes install-time ambiguity (NT simply refuses 486SX/EC68K).

Code-density & front-end pressure (hot loop footprint)

X86: variable-length CISC encodings → tight hot loops (e.g., 12–24 B for small memcpy kernel). 8 KB L1 (486) holds lots of ucode.

68k: also dense; elegant addressing modes (post-increment, scaled indexing) reduce instruction count. Tiny 68030 I-cache (256 B) hurts on larger loops; 68040’s 4 KB/4 KB fixes this.

MIPS: fixed 32-bit encodings; loop bodies are larger but predictable; compiler must fill delay slots to match CISC density/throughput.

Representative microbenchmarks (synthetic; steady-state, warm cache)

1) Integer hot-loop (sum of array, 64 KB, L1-resident)

386DX-33: ~45–55 MB/s (bottleneck on front-end & no L1)

486DX2-66: ~120–150 MB/s

68030-25: ~60–70 MB/s (I-cache thrash beyond 256 B loop)

68040-25: ~110–130 MB/s

R3000-33: ~130–160 MB/s (if load-delay filled)

2) memcpy 1 MB → 1 MB (aligned, write-through)

386DX-33 (REP MOVSD): ~8–12 MB/s

486DX2-66 (REP MOVSD): ~25–45 MB/s (VLB, decent DRAM)

68030-25 (MOVEM/unroll): ~10–18 MB/s

68040-25 (MOVE16/unroll): ~15–30 MB/s

R3000-33 (unroll): ~20–35 MB/s (cache & alignment sensitive)

3) Branchy loop (mispredict-heavy)

386: steep throughput loss (~0.4–0.6 IPC)

486: better (~0.8–1.0 IPC)

68030/040: ~0.8–1.0 IPC if prefetch helps

R3000: fill delay slots; otherwise +1c penalty each miss → ~0.7–0.9 IPC

4) Syscall+return (null system call; ring transition or trap/RTI)

486DX2-66 (NT): ~1.2–1.8 µs

68040-25 (Unix-like): ~1.5–2.2 µs

R3000-33 (Unix-like): ~1.0–1.6 µs (but TLB refill risk)

5) VM stress (random 4 KB page touch across 8× RAM)

486DX2-66: stable fault cost; page-walk in HW → consistent faults/sec

68040-25: similar stability; D-cache reduces penalty

R3000-33: high variance; SW-refill cost dominates tail latency

Why these low-level facts picked the winners

MMU ubiquity on x86 (even SX) created a guaranteed OS target (Win 3.1 Enhanced, OS/2 2.0, NT, Linux). The EC 68k parts remove the very feature UNIX/NT need.

486 on-die cache + 1-cycle ALU moved x86 from “feature-enabled� to throughput-competitive, making REP strings and thunk-free 32-bit I/O real wins in Win95/NT.

MIPS SW-TLB refill is elegant and fast when hot, but tail latencies under random VM made desktop OSes trickier; great for embedded/console (tight working sets), less forgiving for general-purpose desktop thrash.

FPU standardization (Pentium) vs FPU ambiguity (68040 weak, 68060 missing trans ops) shaped OS policy (NT install block) and ISV targets (CAD, DCC).

Encoding density let x86/68k punch above clock in I-cache-limited loops; MIPS relied on good scheduling and bigger caches to keep parity.

Last edited by MEGA_RJ_MICAL on 11-Sep-2025 at 04:13 AM.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL

I agree with most of your points.

68K CPU problem is on Motorola.

For Xmas Q4 1992, Mac LC II had the full 68030 @ 16 MHz, but it wasn't competitive to PC's Am386DX-40 solution.

Mac LC II is the best-selling Mac model for 1992. With 44,000 A1200 units available for Xmas Q4 1992 sale, the A1200 was largely missing in action in 1992.

https://everymac.com/systems/apple/mac_lc/specs/mac_lc_ii.html
Mac LC II's 68030-16 enables paged virtual memory.

Apple responded with
Macintosh LC III with 68030 @ 25 MHz in February 1993.
Macintosh LC III+ with 68030 @ 33 MHz in October 1993.
Macintosh LC 475 with 68LC040 @ 25 MHz in October 1993.
October 1993 releases are important for the Xmas Q4 1993 sales period.

AmigaOS has 32-bit preemptive multitasking, but it can't be enforced since it lacks memory protection. Certain Linux advocates have redefined AmigaOS as cooperative due to unprotected preemptive multitasking.

_________________

We need a fast 68320CPU, really fast, 4 Gigahearts + Multitrashing at least, super deficient short exodus bi-cycles, because one cycle is not enough.

And Meccabytes of super fast GDR ChipRAM Quadro-Ported RAM at least, in HAM32 this Amiga would have broke all boundaries, a super YUV-mode for GFX is abolutely needed and 4 slots especially for Video-Roaster.


I don't know why the lacy developers haven't done this, lacy folks that didn't support the pizza they consumed.

Quote:

Hammer wrote: @MEGA_RJ_MICAL I agree with most of your points.

Friend Hammer,
you just agreed with the result of prompting chatgpt with
"please ramble randomly about cpus"

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL


High-performance CPUs are essential for modern computing, powering everything from intense gaming to complex design tasks, with their speed often measured in Gigahertz (GHz) and expressed in clock speed, which indicates how many cycles a processor can complete per second. Achieving peak performance relies not only on the CPU itself but also on ensuring it doesn't become a bottleneck for other components, such as the graphics card (GPU), a phenomenon known as CPU bottlenecking. To identify and address potential performance issues, you can use the Task Manager to monitor CPU usage and identify resource-hungry applications or services.
Key characteristics of high-performance CPUs:

High clock speeds:
A CPU with speeds of 4.0 GHz and above is excellent for demanding, high-performance tasks like high-end gaming or graphic design.

Core count and architecture:
Beyond clock speed, the number of processing cores and the underlying architecture contribute significantly to a CPU's overall performance, with more cores allowing for better handling of multiple simultaneous tasks.
Balance with other components:
A powerful CPU can only perform at its best if paired with an equally capable GPU and sufficient RAM. If the CPU is too weak for the GPU, it can become a "bottleneck," hindering the performance of the entire system.


By Google AI

@Hammer

Quote:

Hammer wrote: @MEGA_RJ_MICAL I agree with most of your points. 68K CPU problem is on Motorola. For Xmas Q4 1992, Mac LC II had the full 68030 @ 16 MHz, but it wasn't competitive to PC's Am386DX-40 solution. Mac LC II is the best-selling Mac model for 1992. With 44,000 A1200 units available for Xmas Q4 1992 sale, the A1200 was largely missing in action in 1992. https://everymac.com/systems/apple/mac_lc/specs/mac_lc_ii.html Mac LC II's 68030-16 enables paged virtual memory. Apple responded with Macintosh LC III with 68030 @ 25 MHz in February 1993. Macintosh LC III+ with 68030 @ 33 MHz in October 1993. Macintosh LC 475 with 68LC040 @ 25 MHz in October 1993. October 1993 releases are important for the Xmas Q4 1993 sales period. AmigaOS has 32-bit preemptive multitasking, but it can't be enforced since it lacks memory protection. Certain Linux advocates have redefined AmigaOS as cooperative due to unprotected preemptive multitasking.

Like I said, a bot.

_________________
All the way, with 68k

@MEGA_RJ_MICAL

Are you supporting the 386 MMU standard NOT being important for establishing a large enough install base for a memory-protected/preemptive OS's mass deployment?

Any "What If" about the Amiga platform is about Commodore's and Motorola's management direction, NOT at the retail end.

Any "next gen" road map is BEFORE retail release.

_________________

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Why customers / final users should pay for features which were not important and, even more important, no used? A competitive road map is important for end users' investment/spending decisions. Apple's switch to Intel X64 was done by a competitive road map. From April 22, 2003 (K8 Opteron, SledgeHammer) and September 2003 (K8 Athlon, ClawHammer), AMD64 CPU products were released before RTM'd Windows XP X64 (April 25, 2005)'s and Windows Server 2003 X64 (April 2006)'s releases. When AMD attached 64-bit K8 to the mainstream 32-bit PC market, it was game over for Itanium. https://www.youtube.com/watch?v=jB9FrBWrbOA Dave N. Cutler speech on AMD's K8 x64 processors when running developmental Windows XP X64 and Windows Server 2003 X64. Intel's EM64T was officially released in March 2004. All Pentium 4 6xx models, on Pentium 4 5×1 models (like 541, 551, 561, and so on), and also on Celeron D 3×1 and 3×6 models (331, 336, 341, 346 and so on) have EM64T. Intel caught out like IBM's late 386 PC release. Developmental Windows XP X64 and Windows Server 2003 X64 were publicly floating around before the RTM version.

2006 - 2003 = 3 years.

2001 (XP) - 1985 (80386) = 16 years.

Spot the difference...
Quote:

Are you going to argue for MS to complete Windows X64 RTM before starting X64 CPU R&D?

No, to me it's enough to just point out to the dates to prove my point: see above.
Quote:

Are you nuts?

This is the second yellow flag: from the next one, I'll switch back to my previous behaviour against YOUR offences, and you get what you deserve.
Quote:

Both AMD and Intel release CPU feature sets greater than the current Windows RTM. X86-X64's transition mirrors 386's transition. Are you going to argue for MS to complete Windows NT 3.1 RTM before starting 386 R&D? On R&D, the hardware platform vendor needs to cooperate with OS platform providers.

I've already shared it my opinion on my previous post. If it's not clear to you, then it's better that you read it again until you get it.

Hint: I've NOT argued what you're trying to put in my mouth (which is called mystification: something which should avoid in a discussion). To be more clear: I'm only responsible of what I, and only I, say, and NOT of what YOU think that I've said.
Quote:

Bill Gates was already pro-386 in 1985 against IBM's 286-only position!

Sure, sure: https://en.wikipedia.org/wiki/Windows_2.0#System_requirements

The official system requirements for Windows 2.0 include the following.

Minimum system requirements

CPU 8088 processor (80286 or 80386 recommended)

Released to manufacturing December 9, 1987
Quote:

Intel/MS/SCO/Compaq cooperated with the 386AT PC's release in 1986, with Windows 386/Xenix 386 released in 1987.

Already answered.
Quote:

------------------------------------ AMD's RDNA 4.0 already includes hardware features to support incoming RTM'd DirectX Raytracing Tier 1.2. NVIDIA already supports DXR Tier 1.2 OMM and SER features via NVAPI, Cyberpunk 2077's path tracing patch, and ADA Lovelace generation. Are you going to argue for MS to complete DXR Tier 1.2 at RTM state and then start GPU R&D for it? NVIDIA sets the standard, and others follow.

See above: do NOT try to put OTHER words in my mouth.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: The software of the time ran in a completely unprotected environment for very long time: DOS is the clear example of that, but all other mainstream OSes/platforms were doing the same (so, Mac and Amiga). As a platform holder with an ongoing concern, your argument is flawed. Since MS controlled Xenix in 1985 and 1986, Bill Gates already had a pro-386 position in 1985 against IBM's protected mode 286-only OS/2 1.x. MS's venture capital invested in SCO. MS offered Xenix 68K for Apple Lisa/Macintosh XL (with custom MMU) in 1984. MS is already experienced with the 32-bit 68000 + custom MMU Apple Lisa with Xenix 68K offering. MS's internal email transport was running on 68K Xenix servers before being replaced by MS Exchange. Apple took over Macintosh XL/Xenix 68K with Macintosh II (1987) and A/UX (1988). The goal for IBM's OS/2 1.x is to replace MS Xenix 286 and MS-DOS. Remove AT&T's Unix IP. For OS/2 3.0 (aka Windows NT), MS hired Dave Culter (DEC VMS, Mica) and his team in 1988. Windows NT's goal is to replace Xenix 386 and DOS. Remove AT&T's Unix IP. AT&T's Unix license is expensive, hence MS's and Apple's future OS development can't be made on it. Apple's next-gen OS is just Steve Jobs' NeXTSTEP, which was in development from 1986. Rich Page, a NeXT cofounder who formerly directed Apple's Lisa team, led a team to develop the hardware, while kernel engineer Avie Tevanian led the development of NeXT's operating system, NeXTSTEP. NeXTSTEP is effectively a continuation of Apple Lisa (with a custom MMU) and its Xenix option. Quote: IBM failed to use the 80286 on its PC line, because the software continued to use the "good old" DOS applications, which did NOT require the 286's protected mode SELECTORS and, in general, all C2-level protections (which weren't entirely used by Windows, to be precise). Wrong narrative. Refer to IBM Xenix https://winworldpc.com/product/xenix/ibm-pc-100 https://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf Title: Intel 386 Microprocessor Design and Development Oral History Panel Leukhardt: Well we thought that was a key market segment for the 386. It was not a market segment where the 286 was doing well at all; it was a market segment where the 68000 was cleaning up principally because the 286 was not viewed as a machine that ran Unix well and the 68000 was viewed as a natural Unix machine. So when we were working on the 386 definition we wanted it to have as one of its attributes being able to run Unix well. So that’s one of the things that influenced us in terms of wanting to have a way to run the 386 as a flat 32-bit machine, and that’s one of the things that led to all the angst in the definition process about compatibility versus a flat 32bit machine and how they would coexist. 386's integrated PMMU was a competitive one-up against 68K's Unix. Intel 386 went beyond #Metoo R&D since Unix 68K+MMU had separate chips prior to 1987's 68030. Slager: In all the earlier battles for some reason the addressability was way down the list. And we spent huge amounts of energy arguing about some little instruction or something that some customer wanted. And we just didn't get the attention on the addressability. And now it's easy to see how it should have been done at the 286 definition. If it hadn't been for that Zilog MMU we might have stumbled into the right approach. But there were really only two priorities. One was 32 bits, which we just totally missed, and the other was a path toward virtual memory. And the right path would have been not to do it with the 286 but to leave it for paging in the 386, which is really what other architectures did. They didn't do a segmentation model at all, they just did paging and it did all the protection that they needed and all the memory management. I don't know how things would have changed if we had stumbled onto the right path, but we sure had it backwards in those days. To look back at it, it might have given Intel an advantage to have the complex segmentation, which was largely unused from the 386 on, because it made it difficult for other people to second source it. It was a problem for us to design, but that same problem was there for everyone else. Eventually AMD mastered it, but I don't know if you ever master it, because it takes a lot of testing and a lot of design capability. Intel engineers blame the 286 MMU design on Zilog's competition influence instead of focusing on Unix 68K competition.

You completely forgot the original context of the discussion, which was about MAINSTREAM/CONSUMER OSes.

I've already replied on that, and also clarified on my comment #5: no need to repeat again the same things like a parrot.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Which is a very good thing, because the right point here is offering the needed functionalities depending on the specific requirements, and Motorola perfectly fit that with its processors line: - fully fledged (all features: FPU + PMMU); - without FPU; - without FPU and without MMU; - reduced address bus lines. https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf DataQuest 1991, page 119 of 981 For 1992, 68EC020-16, $16.06 68EC020-25, $19.99 68020-25, $35.13 68EC030-25, $35.94 (missing MMU, not Unix capable, used in A4000/030) 68030-25, $108.75 68040-25, $418.52 68EC040-25, $112.50 (missing MMU and FPU) AM386-40, $102.50 R3000-25, $96.31 386DX-25, $103.00 80486SX-20, $157.75 (still has MMU for Xenix 386, Windows NT, and Linux) 80486DX-25, $376.75 80486DX-33, $376.75 80486DX-50, $553.25 80486DX2-50, $502.75 Notice Motorola's 68030-25 follows Intel's 386DX-25 price guidance until both are stumped by AM386-40.

Completely irrelevant regarding the context of the discussion on this part.
Quote:

All 32-bit X86 CPUs have an MMU.

Irrelevant regarding the original discussion and my last summary (post #5).
Quote:

https://www.electronicproducts.com/mips-processors-to-push-performance-and-price/ From 1992, IDT MIPS R3040 @ 20 Mhz has $15 price, that's a poorman's 68LC040 1 IPC class with a budget price.

Totally irrelevant as well.
Quote:

PlayStation 1's LSI Logic R3050 selection is a no-brainer.

Which PMMU was embedded on the PS1 CPU? You're still NOT answering: guess why...

This, as well as the other question, which I reiterate: starting from which console the PMMU was mandatory (read: absolutely needed)?

Why don't you answer?