Computer history: MC68xxx vs. x86
Maxim S. Shatskih
Was 68040 faster then 486?
Was 68020 faster then 286?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Fabio Alemagna
> Which CPUs were faster in pre-Pentium era - Motorola or Intel?
> Was 68040 faster then 486?
> Was 68020 faster then 286?
The 680x0 have always been faster, per Mhz, than Intel x86's up to the
586@100Mhz, but since the last 680x0 was the 68060@60Mhz, of course it
stopped there.
--
"Everything is vague to a degree you do not realize till you have tried
to make it precise"
| Bertrand Russell
falemagn (AT) aros (DOT) org | The Philosophy of Logical Atomism
Bryan Bullard
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:bvbmil$1vk9$1...@gavrilo.mtu.ru...
as far as clock speed, i think they we're pretty neck and neck then.
i believe the 68030 ran at about around 32 mhz. comparable to the i386.
-bryan
w m r
> Maxim S. Shatskih wrote:
> > Which CPUs were faster in pre-Pentium era - Motorola or Intel?
> > Was 68040 faster then 486?
> > Was 68020 faster then 286?
>
> The 680x0 have always been faster, per Mhz, than Intel x86's up to the
> 586@100Mhz, but since the last 680x0 was the 68060@60Mhz, of course it
> stopped there.
Another fine example of mediocrity winning out.
Mike
Maxim S. Shatskih
More - "of schizoidness". Unnecessary complexity for the sake of complexity, to
enjoy complexity, and lack of propertly engineered design.
I mean the x86 opcode set with all these segments, TSSs and such. x86 was a
slow CPU till Pentiums, slow and eating a lot of power - all of this due to
schizoid opcode set with unnecessary complexity. It was physically impossible
to implement a piece of silicon which will run all this stuff with a good
speed.
On the other hand, MC680x0 had simpler and more clear opcode set, so it was
physically possible to make a simpler and faster CPU. The result? 68xxx felt OK
on the "heavy" workstation market (Suns), where the PCs and x86 were not
treated seriously.
Well, even ARMs were faster then contemporary pre-Pentium x86. Faster while
having by far smaller power consumption. MicroSparc/Tsunami was nearly equal to
486 in performance, while being by far cheaper and lesser consuming.
And all of this segment idiocy in x86 really gave nothing to users and system
programmers. What it really gave? Ability to run the idiotic MS-DOS, which was
designed for this idiotic opcode set? Ability to be proud of setting up The
Ultimate Config.Sys with EMM386 and such, so Lots Of Low Memory is available?
How funny.
Sorry, but UNIXen on 680x0 (like SunOS) were by far superior to MS-DOS, even
with all these add-ons like EMS/XMS/DPMI.
w m r
> > Another fine example of mediocrity winning out.
>
> with all these add-ons like EMS/XMS/DPMI.
And I say again, another fine example of mediocrity winning out ;)
Of course, Alpha chips were the best thing ever, 64-bits in the era of
people wooing over Win3.1 16-bit trash. They were killed off in favor
of the unsinkable inferior Ititanics. Yet another fine example of
mediocrity winning out.
Mike
Maxim S. Shatskih
> of the unsinkable inferior Ititanics. Yet another fine example of
Dunno how Itanium is worse then Alpha. In native mode, Itanium is the fastest
CPU ever made. It is slow on x86 emulation though, but this is another song.
KVP
> More - "of schizoidness". Unnecessary complexity for the sake of complexity,
> to enjoy complexity, and lack of propertly engineered design.
> I mean the x86 opcode set with all these segments, TSSs and such. x86 was a
> slow CPU till Pentiums, slow and eating a lot of power - all of this due to
> schizoid opcode set with unnecessary complexity. It was physically impossible
> to implement a piece of silicon which will run all this stuff with a good
> speed.
The original 8086 was designed to be a microcontroller. It's instruction set
was a bit complex, but elegant in a way that it was designed not to be
upgradable or extendable. It's main goals were simple circuit design and
a similar instruction set as earlier intel microcontrollers. It's segmented
design was a simple hack to allow more memory than 64Kb, but it was not
intended to be used with more than 1Mb. The segmentation was to be used for
memory management purposes too. (you set a segment base on a array and
access it with 16 bit offsets) 16 bytes per heap node was a good tradeoff
for a small single process cpu.
> On the other hand, MC680x0 had simpler and more clear opcode set, so it was
> physically possible to make a simpler and faster CPU. The result? 68xxx felt
> OK on the "heavy" workstation market (Suns), where the PCs and x86 were not
> treated seriously.
The M68k line was designed to be a 32 bit cpu. (with a few features removed
from the original M68000 to decrease its transistor count)
> Well, even ARMs were faster then contemporary pre-Pentium x86. Faster while
> having by far smaller power consumption. MicroSparc/Tsunami was nearly equal
> to 486 in performance, while being by far cheaper and lesser consuming.
The i80386 was a hack on the i80286, that was a hack on the i8086, and none
of these hacks were meant to be upgradable or extendable. The designers were
always sure that the x86 line will end, and there is no need to leave space
for future extensions.
> And all of this segment idiocy in x86 really gave nothing to users and system
> programmers. What it really gave? Ability to run the idiotic MS-DOS, which was
> designed for this idiotic opcode set? Ability to be proud of setting up The
> Ultimate Config.Sys with EMM386 and such, so Lots Of Low Memory is available?
> How funny.
> Sorry, but UNIXen on 680x0 (like SunOS) were by far superior to MS-DOS, even
> with all these add-ons like EMS/XMS/DPMI.
The msdos system was a 16 bit system, that was designed as an alternative to
the cp/m system (like linux was an alternative to commercial unixen).
Microsoft hacked the 32 bit support into an os that was designed for 8 bit
micros having only 64Kb ram. It is possible but it will look horrible. (dos
really looks horrible with its extensions)
On the other side, M68k cpus were designed to host unixen. Their mmus and
protection rings were made just for that purpose. (to support a full blown
os with multiple processes)
Viktor
Miguel
> On the other hand, MC680x0 had simpler and more clear opcode set, so it was
And because of this it wasn't interesting to develop for 680x0 :-)
Good luck
Miguel
Martin Baute
news:J1fSb.12305$hl6....@newssvr23.news.prodigy.com...
>
> as far as clock speed, i think they we're pretty neck and neck then.
> i believe the 68030 ran at about around 32 mhz. comparable to the i386.
I remember contemporary accelerator cards for Amigas running 68030 at 50
Mhz.
Later they were even some specimens at 75 MHz or more. The 68040 was slower
in clock speed (and higher in heat output), whereas the 68060 was back to 50
Mhz
and more, again.
--
Martin Baute
so...@rootdirectory.de
Stephane Hockenhull
"Maxim S. Shatskih" wrote:
>
> And all of this segment idiocy in x86 really gave nothing to users and system
> programmers. What it really gave? Ability to run the idiotic MS-DOS, which was
actualy the goal of the 8086's CISC instruction set was to have the
smallest code because memory (rom and ram) was costly back then.
I dont know any other CPU that can do more than a 8086 in as little or
less memory.
its slow (running microcoded instructions), it has segmentation (saves
on pointer sizes), but its code size when skillfully hand-coded is as
small as can be.
and one reason why newer x86 processors can run so efficiently compared
to its memory bus speed is because of that small code footprint, more
code fits into cache and more code gets thru the limited memory
bandwidth and it gets "decompressed" into multiple RISC opcodes for the
cpu core to run.
IA32 is quite an horrible design, a patch (386) over a patch (286) over
an extention (80186) over a 16bit (8086) inspired design from an 8bit
cpu (8080, Z80) which might have (altho I'm not sure as I havent seen
its instruction set) come from the 8008/4004.
and I dont know about 680x0 but an ARM t-something-7 can process around
4 times more audio signals than a 486 at the same clock rate (however
for other stuff its pretty much equal).
to be fair, IA-32 isnt good at anything (other than tiny code size) but
its pretty decent at everything. there isnt a generic processor out
there that can emulate another one as well as an x86 (except maybe
transmeta, but those were designed for x86 emulation), it can do pretty
much everything: read unaligned data, process 8, 16, *AND* 32bit values
with all its result flags, work with BCD numbers, 32bit, 64bit and 80bit
floating points...
--
Stephane Hockenhull
Fabio Alemagna
> it can do pretty
> much everything: read unaligned data, process 8, 16, *AND* 32bit values
> with all its result flags, work with BCD numbers, 32bit, 64bit and 80bit
> floating points...
MC 680x0 can do all that as well (unaligned data being accessible from
the 020 onwards), and the instruction set is way more orthogonal.
Richard Campbell
Without even BEGINNING to point at previous CPUs (*cough* PPC *cough*
alpha *cough*), AMD's opteron owns Itanium, don't believe me? run a few
benchmarks. And yes we are talking native 64 bit mode and not 32 bit
emulation, though to be fair, you can use emulation on the opteron if
you think it'll handicap it ia little. Doesn't make a difference.
w m r
> Umm...no? Itanium is NOT the fastest and never was.
>
> Without even BEGINNING to point at previous CPUs (*cough* PPC *cough*
> alpha *cough*), AMD's opteron owns Itanium, don't believe me? run a few
The unsinkable Ititanic...
http://www.theinquirer.net/?article=16868
I just wish half the money that was dumped into that thing got dumped
into Alpha instead. HP would have been better off with all the VMS
and Unix stuff they had already running on Alpha. Oh well.
Anyway, good for AMD. My first PC was an AMD 486 with Linux (some
Slackware with kernel 1.3 or some such).
Mike
Scott Wood
> Without even BEGINNING to point at previous CPUs (*cough* PPC *cough*
> alpha *cough*), AMD's opteron owns Itanium, don't believe me? run a few
> benchmarks. And yes we are talking native 64 bit mode and not 32 bit
> emulation, though to be fair, you can use emulation on the opteron if
> you think it'll handicap it ia little. Doesn't make a difference.
Actually using *emulation* would very likely hurt performance on the
Opteron. Running in 32-bit mode, OTOH, is basically a matter of
turning off some features (and turning on others), and will probably
hurt performance a little bit on the Opteron due to the smaller
software-visible register set, but not that much.
-Scott
Will R
>Opteron. Running in 32-bit mode, OTOH, is basically a matter of
>turning off some features (and turning on others), and will probably
>hurt performance a little bit on the Opteron due to the smaller
>software-visible register set, but not that much.
>
>-Scott
>
>
Considering Opteron boots the same way as any other X86 processor, running it
in 32 bit mode isn't as much about turning things off, as not specifically
taking the extra few steps and kicking it into 64 bit mode. Opteron will
natively boot DOS, Windows, or any other 16/32 bit OS just as if it were a 386
clone. It just has a few tasty bits tacked on. :) Very tasty. :)
------------------
A board certified thin-foil chapeautinist, and practicing AluFoil
Haberdasherer.
http://apple.slashdot.org/comments.pl?sid=100795&cid=8595566
Remove SPAM block from email
w m r
> A board certified thin-foil chapeautinist, and practicing AluFoil
> Haberdasherer.
> http://apple.slashdot.org/comments.pl?sid=100795&cid=8595566
Ok, let me see on this one... Heard of scalar electromagnetics? No
tin-foil hat is going to shield from that. Anyway, if it did,
wouldn't you need to enclose your whole head, incl eyes, face, and
going THROUGH your neck?
Give it up, THEY are much more sophisticated than that. One can't
have a private conversation, nay a private *thought*, anymore.
Mike