68k details

[Gorf]

Originally Posted by hooverphonique

Yes, the buster chip supports static column page mode, and the kickstart enables it (and cache burst) if you have an 030, as far as I'm aware.

FatBuster is responsible for ZorroIII - there is also a "Burst-Mode" but that is not what we are discussing here.
"Ramsey" is the chip dealing with the RAM - and yes it supports the 030 Burst-Mode with Fast-Page and with Static Column

[plasmab]

I wanna see those shorter damnit! They hypnotise me



EDIT: this is an 68020 being forced to pretend its a 68K.. but you get the idea.

[pipper]

Can the FPU operate while the cpu is waiting for the bus? Maybe one could hide float calculations in the latency of cpu memory access. I’m thinking of for instance hiding fpu calculations in a C2P routine which are largely chipmem access bound (“at write speed”) on 040 or 060. So instead of twiddling thumbs, while the cpu is waiting for the writes to go through, the fpu could continue producing results...

[plasmab]

The plain 68000 doesn’t even have a coprocessor interface. It needs memory mapped and thats 4 cycles and some CPU reads/writes to do it. It’s pretty awful in terms of setup.

Once the FPU has what it needs it’s less awful and can indeed spend lots cycles executing internally without blocking anything.

But it cant read or write to ram itself. Even instructions have to be issued by the CPU

But I’ll forgive the plain 68000 for being awful here as the coprocessors didn’t exist when the chip was designed.

[hooverphonique]

Originally Posted by Gorf

FatBuster is responsible for ZorroIII - there is also a "Burst-Mode" but that is not what we are discussing here.
"Ramsey" is the chip dealing with the RAM - and yes it supports the 030 Burst-Mode with Fast-Page and with Static Column

I meant Ramsey of course

[plasmab]

Completely randomly i started thinking about what biscuit a CPU would be if it were one... starter for ten...

Z80 = Stale Ginger Snap
6502 = Custard Cream
8086 = Rich Tea
68000 = Plain Digestive
68020 = Plain Chocolate Digestive
68030 = Milk Chocolate Digestive
68040 = Caramel Digestive
68060 = Banoffee Caramel Digestive
ARMv2/v3 = Hobnob

...

Silly but...

[plasmab]

Ok that was a bit strange... even for me.

[Paulee_Bow]

Originally Posted by plasmab

Ok that was a bit strange... even for me.

8086 is totally rich tea.

We need to admit to ourselves that the rich tea, no matter how you dress it up, is not a good dunker. They’re best eaten crisp, dry and on their own, rather than the soggy mess you’ll get when dunked.

My Amiga 500+ has a 33mhz 68000 that can outperform an A1200 at 16-bit stuff. Would this faster digestive be spinning too fast to maintain its structural integrity and become a cheesecake base? The system also has 8MB of fast Ricotta And Mascarpone.

Tortured, that joke was.

[plasmab]

Actually the z80 is a water biscuit

[Paulee_Bow]

Originally Posted by plasmab

Actually the z80 is a water biscuit

Like a pink wafer? A caramel wafer? Or maybe one of those wafers you put in ice cream?

[plasmab]

Originally Posted by xanderbeanz

Like a pink wafer? A caramel wafer? Or maybe one of those wafers you put in ice cream?

More like

[Locutus]

Some cracking jokes you got there.....


(i'll show myself out)

[plasmab]

Originally Posted by Locutus

Some cracking jokes you got there.....


(i'll show myself out)

Oh boy... that hurt


Sent from my iPad using Tapatalk

[litwr]

Thanks to everybody who has paticipated the discussion. I meanwhile have prepared some more texts. I can even have translated my article about Motorola 6800 family - https://litwr.livejournal.com/1396.html

Originally Posted by meynaf

Yes 68020 does not have built-in memory management but a 68451 can be added to fix this - using that ability to connect coprocessors that you seem to dislike.

Of course 68040 is still faster than 80486 - but indeed heats too much and has shortcomings so it started to kill the 68k family.

With all that said, comparison of processors may be a lot easier by writing code (a routine doing the same thing) for each of them. Something around 100-200 instructions, without OS dependencies that may falsify the result.

It would be fun to see code (and actual encoding) compared for 68k, x86, and arm (and whatever else). But who will write the x86/arm code?

Having co-prossesor is worse than to have it built-in.

Try to ask yourself why 68040 has shortcomings? Maybe because its ISA was too bulky and large to support in 1990... Intel ISA was much lighter that year and it had fairly won the race.

It is an interesting challenge but 100-200 instructions of high optimized code can require more than a day. I am ready to this contest only if we limit ourselves to no more than 50 instructions.

Originally Posted by meynaf

Overall the tone says it clearly : in 68k page it was "bad" cpu and here it's "good" cpu. *Cough*.

The 8086 isn't "one of the best processors made in the 70's". Actually, one of the worse. It would have disappeared long ago if it weren't used by IBM on the PC (for economic reasons and nothing else).

While the architecture indeed doesn't adhere to abstract theories, it's nothing about balance nor steadiness either (and not even further development).
It has shortcuts for relative rare operations, some common things are just missing, and so on. Yukk.

And, oh, yes. The segmentation stuff is far from "brilliant". Actually one of the worse things ever invented.
While it may look good in the paper, it's the typical thing that only works in theory - in practice, segments were too short and it led to the near/far pointer horror.

I can just laugh when reading :
"It's hard to say that in the 8086 command system, something is clearly missing. Quite the contrary."
Well, the most problematic are already mentioned in the above post. But it's true that the main issues are with addressing modes, and restricted use of registers.

Talking about "ease of programming" in case of x86 looks like the author never attempted to write any code.

It's true that many instructions have several opcodes. You may also mention the "de-facto standard" of TEST instruction duplicated at F6-F7 /1.

If you still think x86 is a good cpu overall, i suggest you try to write a disassembler in asm for it (I did that for 68k long ago). There you will more clearly see all the quirks, the first being that it's impossible to know about all the extensions that have been added in "modern" iterations. Say, for example what's encoded at 0F 38 xx exactly, i can't tell.

You are not right about the tone of the article. It is you who says about bad and good CPUs. You have used too many general words in your 8086 critics - please be more specific. Why near/far subroutines are horrific for your? It is quite easy. If you have a lot of code just mark some of your subroutine as far. Indeed the segments are no good for big arrays but such arrays were quite rare for PC codes up to the second half of the 80s. Even with big arrays we have only some slowdown.

I have written at least 50000 lines of x86 codes. I am even the author for the first in our world emulator for the one of the best Commodore computers - http://litwr2.atspace.eu/p4_download.html My works with 68000 can only collect less than 5000 LOC. I wrote also several small programs for 68020.

Why did IBM choose 8088? IMHO Because it was the best for that time. Indeed the word the best means the best overall: in speed, in price, in availability, in reliability, in prospectivity, etc. 68000 was more expensive and had only several minor advantages.

I have written about several x86 oddities with opcodes but they don't affect practical programming. BTW thanks for the mention this double TEST issue.

It looks like that you try to transfer you inability to handle modern and complex processors to these processors themselves! It looks quite illogical. I have heard that a mirror can help in some such cases. Be less lazy, work hard and all x86 surrender to you.

Originally Posted by roondar

I'll have to agree with meynaf here: the Motorola article does seem to be rather biased against the MC68k series. Not sure what you want out of this, really.

Sorry if you have understood it in this way. The spirit of my humble work is in a cliche words "nothing is perfect". 68000 has its shortcomings so as 8086. IMHO 68000 looks like a boxer with very strong right arm but with artificially mutilated left arm. 8086 is more balanced and healthy. Yet again I repeat it is MHO only.

Originally Posted by Thorham

Indeed. Have fun implementing a multitasking OS with only one stack, for example.

Couldn't agree more. Having 16Mb address space on the 68000 is fantastic. Sure, in 1979 that would've been a bit much, but Motorola was clearly thinking of the future here. Same with the brilliant idea of making the instruction set 32bit.

What is wrong with x86 multitasking? It works quite fine.

I can repeat that up to the second half of the 80s RAM amount above 1 MB was an enormous luxority. Who could afford it in 1982? Almost nobody. Intel 80286 was released in 1982 with the support of 16 MB too - it was much more right time for that amount of RAM. Motorola forced users to pay for features that couldn't be used. Indeed 16 MB theoretically was fantastic but practically it was just a pretty illusion. How many ppl had Amiga 500 with more than 1 MB memory in 1990? I think only a few. That time cheap 80286 and even 80386 systems became widely available and they were up to ten times faster than 68000 at 7 MHz.

Originally Posted by chb

I see the problem to get reliable benchmarks for such old hardware, but The ones given in the BYTE article are just nonsense for your comparision, they measure BASIC and disk/file access between three very different operating systems and basic interpreters - so almost zero meaning for determining CPU performance.

They measured the performance of ordinal applications. So a Mac user had a system that worked slower than PC XT and only slightly faster than Apple IIe. I have some explanation for the fact that Mac showed itself so slow. It is because of the time period for the software development: Apple II had its 7 years, PC XT - more than 2 years, Mac had less than 1 year. However it arises a question Why software for Mac was so slow?

Originally Posted by ross

Have you ever thought of using a move.x dx,[ea] instead of clr.x [ea]? (where dx=0, in 68k you sure have a spare register, unlike other micros).
Fast and without 'hardware bug' (if you really want to call it this bad implementation).

Really?!? and lea $abs.w,ax and movea.w source,ax what do they do?

Why does anybody have to use MOVE instead of CLR where the latter is dedicated for the task? I've only written that such CLR implementation is an irritating oddity.

I have written that 68000 full address requires 4 bytes to load and one of them is excessive but you have to load it too.

Why people try to compare x86 and 68k here? Let's talk about them separately. It is not about what is the best thing. All things in this world have their flaws.

Originally Posted by roondar

It rather famously has a pretty scary bug in the way it deals with interrupts, where using a pop instruction can lead to interrupts being re-enabled without the programmer ever asking for this. Interrupt code on 8086/80186/80286 has to work around this.

This bug was part of the architecture until the 386, so users of x86 where forced to work around this bug and didn’t have an alternative to use a corrected CPU.

Real world performance of a 6MHz Mac, or an 8MHz Atari ST is much higher than these benchmarks claim. A 6502 at 2Mhz will not even get close to a 68000 at 6 (or 8) MHz. For any task.

Benchmarks from the 1980s are tricky things, because they tend to be very unreliable. For instance, check the link here: https://tech-insider.org/unix/research/1986/0219.html

Results are all over the place, with the 68000, 8086 and 286 losing and winning versus each other purely based on what compiler was used to compile the benchmark program. This tells us that relying on benchmarks is a bad idea, they may end showing a system as seemingly faster or slower, when in fact it might just be a poor compiler or poor implementation that’s causing the differences.

In that case, do let me know when you’ve rewritten your article to be factual by removing the errors pointed out in this thread. You haven’t changed anything yet, even though many factual errors have already been pointed out.

Of course they have great impact on executing code. They greatly simplify code compared to not having this option, which means less code to execute. This is one of the many reasons that 68k processors have to execute fewer instructions to do the same job as an 8086.

And err, 68000 has relative jumps as well. Both 16 bit and 32 bit relative if needed.

roondar, thank you very much about mentioning x86 interrupt bug. Could you be a bit more specific? Any links will be greatly appreciated. That bug sounds very serious but it contradicts the fact that tens millions of 8086/8088/80286 PCs which were used with it...

I think you underestimate 6502. It can be very fast with byte manipulations, control structures, boolean data, ... Try to imagine, for example, a loop which has to add 77 to each byte in 4 KB byte array. 6502 @2MHz can beat 68000 @8MHz here. Indeed 16/32-bit arithmetic is faster with 68000 and division is much faster.

Thank you for the benchmark link. However it confirms my point that 68000 is generally a bit faster than 8086 and about 50% slower than 80286. Let's see the best values for each CPU.

Sorry but I can't still get any fact that contradicts the content of the article. I have some personal points of view only.

Indeed relative jumps at 8086 or even 80286 are poor point but 8088/8086 executes one branch jump for 4/16 clocks (10 on average) and 68000 for 12/18 cycles (15 on average). 80286 requires only 3/7-11 (6 on average) in this case.

Originally Posted by meynaf

As already said, x86's code density drops completely when projects become larger.

The game versions are identical, only thing is that Mac 68k version does not have midi music but sound drivers are external in x86 version.
And so is the smack player in the windows version, yet the exe is still bigger...

True, but not enough to compensate for the fact it needs less instructions to do the same job.
In comparison, 68000 can use word and longword sized operations without size penalty.

I measured my Atari ST was ~14 times faster than my Oric back in the day. It could easily have 16,000 interrupts per second (a likely case in some audio apps), where a 80286 would max out at something like half that amount.
And 8088 is (i believe) slower than similar clocked 6502 (perhaps not 8086).
Too bad i can't do this kind of benchmarks anymore :/


Strange argument for someone saying he rejects theories and prefers being based on real life experience...
There is no benefit vs locked ADD instruction (in real life we don't need the original value of the memory location).
If you really think it's usefull, well... as usual i want to see the code.

Not of much use because this only works on registers. TST can operate on memory directly (and I do that all the time !).

We were talking about code density weren't we ?
And just about every cpu has relative jumps, no ?

I respect you important opinion that x86 has poor code density. However can you give any link which confirms your respectable point?

I remember playing https://en.wikipedia.org/wiki/Defender_of_the_Crown . I played in with my A500 but later I tried it with IBM PC clone. The PC graphics and sound looks much poorer (I used CGA and the beeper) but PC version has some additional animations and features. So it were generally similar but different games.

I agree that with 32-bit arithmetic 68000 is quite possible only slightly slower that 80286 but with 16 bit it is much slower. Indeed 68000 is much faster that 8088 with 16-bit arithmetic.

I agree that 8088 or even 8086 is generally slower than 6502 at the same frequency but it can be faster in some important cases.

I can't understand why 16000 interrupts per second so impressed you - it is possible even with 6502 @1MHz.

Indeed 68030 is even IMHO better than 80386.

The locked add is enough for the implementation of a mutex but if you want something more complex like https://en.wikipedia.org/wiki/Non-blocking_algorithm you will need more complex instructions.

However, the short sequence MOV AX,mem; TEST AX,const at 8086 can be faster than TST mem with 68000.

Of course, for the code density 68000 relative jumps can be better sometimes. However 8086 can use sometime 2 bytes for such jumps, in a 16-bit jump case it is still only 5 bytes.

@meynaf, thank you very much for your 68000 shortcomings list.

[ross]

Originally Posted by litwr

Why does anybody have to use MOVE instead of CLR where the latter is dedicated for the task? I've only written that such CLR implementation is an irritating oddity.

Yes, an oddity but not so irritating, just a little slower than it should be.
Anyway known by 68k programmers who can use the alternative that I have suggested that has no problems and is faster.

I have written that 68000 full address requires 4 bytes to load and one of them is excessive but you have to load it too.

I really don't get your point here..
How you can have a full 32bit machine without a 4 bytes register? (every Amiga programmer know the bad from upper byte alternative usage..)
Ok, you have 24 address lines but the project was for a future full 32bit addressing support from the start.
And if you like a '0 page' you can have two with the short form lea .w
(the upper page really even used by Atari ST for custom register).
Or you prefer the segmented 8086 horror?

Cheers

[meynaf]

Originally Posted by litwr

Having co-prossesor is worse than to have it built-in.

Why ?
No, this is not true. If it's external then you can choose what's there and what's not.

Originally Posted by litwr

Try to ask yourself why 68040 has shortcomings? Maybe because its ISA was too bulky and large to support in 1990... Intel ISA was much lighter that year and it had fairly won the race.

Well, much lighter, not really. But Intel already had more financial means due to massive peecee sales, and that's the one and only reason why it won the race - and not at 68040 because it's still faster than 80486.

Originally Posted by litwr

It is an interesting challenge but 100-200 instructions of high optimized code can require more than a day. I am ready to this contest only if we limit ourselves to no more than 50 instructions.

100 instructions of high enough optimized code would take me 1 or 2 hours. Seems i have better ISA than you do
But perhaps you know the x86's density will start to fail if you go over that amount ?

Well, anyway. That's ok for 50. Just give me a little time to find a suitable routine (or choose one if you prefer).

Originally Posted by litwr

You are not right about the tone of the article. It is you who says about bad and good CPUs.

Your article is clearly biased, and i am not alone having seen that.

Originally Posted by litwr

You have used too many general words in your 8086 critics - please be more specific.

I could just replace 8086 by 68000 and return that sentence to you.
YOU are the one with the unusual claims. So YOU have to prove what you say.

Originally Posted by litwr

Why near/far subroutines are horrific for your? It is quite easy. If you have a lot of code just mark some of your subroutine as far. Indeed the segments are no good for big arrays but such arrays were quite rare for PC codes up to the second half of the 80s. Even with big arrays we have only some slowdown.

That's an additionnal, useless constraint. And i hate additionnal, useless constraints.

Originally Posted by litwr

I have written at least 50000 lines of x86 codes. I am even the author for the first in our world emulator for the one of the best Commodore computers - http://litwr2.atspace.eu/p4_download.html My works with 68000 can only collect less than 5000 LOC. I wrote also several small programs for 68020.

If you take one day for 100 lines, this should have taken you your whole life

Originally Posted by litwr

Why did IBM choose 8088? IMHO Because it was the best for that time. Indeed the word the best means the best overall: in speed, in price, in availability, in reliability, in prospectivity, etc. 68000 was more expensive and had only several minor advantages.

Apparently you do not know the story behind.
If they wanted speed, they would at least have chosen 8086.
68000 didn't have just minor advantages : if it weren't for the IBM PC, it would have killed intel.

But IBM did not believe that their 5150 could have a future (yes they were that stupid) and preferred low price over quality. They could already buy cheap intel chips and this is what they did. They didn't bother copyrighting more than the BIOS and we all know the result.

https://forwardthinking.pcmag.com/ch...-an-intel-8088

Originally Posted by litwr

I have written about several x86 oddities with opcodes but they don't affect practical programming. BTW thanks for the mention this double TEST issue.

Yes they don't affect practical programming, but neither do the two stacks of the 68000.

Originally Posted by litwr

It looks like that you try to transfer you inability to handle modern and complex processors to these processors themselves! It looks quite illogical. I have heard that a mirror can help in some such cases. Be less lazy, work hard and all x86 surrender to you.

... says the one blocked in 80386 region (ever tried using intel's bmi2 or tsx extensions for example ?) and needing to take one day for 100 miserable instructions.
That's preposterous, really.

What's your goal when coming here anyway ?

You look like a troll, coming here to get trouble. You come on a rather 68k-oriented forum and say basically that 68k sucks and x86 rules. What do you expect ? That some of us will end up so pissed off they will lose their self-control, write name-calling and ultimately get banned ?

Originally Posted by litwr

Sorry if you have understood it in this way. The spirit of my humble work is in a cliche words "nothing is perfect". 68000 has its shortcomings so as 8086. IMHO 68000 looks like a boxer with very strong right arm but with artificially mutilated left arm. 8086 is more balanced and healthy. Yet again I repeat it is MHO only.

Looks like you find an abacus "more balanced and healthy" than a pocket calculator. There is a world between the two.

Originally Posted by litwr

What is wrong with x86 multitasking? It works quite fine.

First, it doesn't work "fine". It took Microsoft 20-30 years to get it roughly right (vs a few months for Sassenrath to write Exec).
Second, that's for protected mode ONLY (where, how odd, you DO have several stacks).

In fact x86 is so poor in multitasking they had to put several cores in the same chip to have a proper one !

Originally Posted by litwr

I can repeat that up to the second half of the 80s RAM amount above 1 MB was an enormous luxority. Who could afford it in 1982? Almost nobody. Intel 80286 was released in 1982 with the support of 16 MB too - it was much more right time for that amount of RAM. Motorola forced users to pay for features that couldn't be used. Indeed 16 MB theoretically was fantastic but practically it was just a pretty illusion. How many ppl had Amiga 500 with more than 1 MB memory in 1990? I think only a few. That time cheap 80286 and even 80386 systems became widely available and they were up to ten times faster than 68000 at 7 MHz.

Yeah, we know, 640kb should be enough for everyone.

Originally Posted by litwr

Why does anybody have to use MOVE instead of CLR where the latter is dedicated for the task? I've only written that such CLR implementation is an irritating oddity.

I don't use MOVE instead of CLR. Actually when i was still coding for 68000 (not 68030) i did not even know about that bug...

Originally Posted by litwr

I have written that 68000 full address requires 4 bytes to load and one of them is excessive but you have to load it too.

One of them might seem "excessive" but it's a bet for the future. Properly written software works in 32-bit as well. Does 16-bit x86 code work in 32-bit mode ?

Originally Posted by litwr

Why people try to compare x86 and 68k here? Let's talk about them separately. It is not about what is the best thing. All things in this world have their flaws.

Fearing you will lose the comparison ?

Originally Posted by litwr

Try to imagine, for example, a loop which has to add 77 to each byte in 4 KB byte array. 6502 @2MHz can beat 68000 @8MHz here.

I hope this is a typo. Else you're writing just plain crap, sorry.
Because for 68000 it looks like 16 clocks for ADDI, 10 for DBF. For beating this a 2Mhz 6502 needs to do it in 6 clocks per byte - mere LDA+STA pair already covers this easily.

Originally Posted by litwr

I respect you important opinion that x86 has poor code density. However can you give any link which confirms your respectable point?

Unfortunately code density studies are scarce, to say the least.
But it's quite easy to find the same game (with exact same features !) for two platforms and compare executable size, even though this is biased because of compiler differences.
This is why i keep asking for actual code.

Originally Posted by litwr

I remember playing https://en.wikipedia.org/wiki/Defender_of_the_Crown . I played in with my A500 but later I tried it with IBM PC clone. The PC graphics and sound looks much poorer (I used CGA and the beeper) but PC version has some additional animations and features. So it were generally similar but different games.

What's the point here ?

Originally Posted by litwr

I can't understand why 16000 interrupts per second so impressed you - it is possible even with 6502 @1MHz.

But 6502 @1Mhz can't mix 4 audio channels in the interrupt at that rate. 8Mhz 68000 can, while still displaying a GUI.

Originally Posted by litwr

The locked add is enough for the implementation of a mutex but if you want something more complex like https://en.wikipedia.org/wiki/Non-blocking_algorithm you will need more complex instructions.

And again, theory, theory, just theory. Please show actual code getting benefit of XADD.

Originally Posted by litwr

However, the short sequence MOV AX,mem; TEST AX,const at 8086 can be faster than TST mem with 68000.

Ahem... no.

According to googled doc :
http://www.oocities.org/mc_introtoco...ion_Timing.PDF

MOV AX,mem is 8+EA.
TEST AX,const is 4.

68000's TST is 4+EA (with perhaps EA somewhat larger than x86's).

And forget it if you know some "special case". Statistically it's insignificant in comparison to the 68000 performing MOVE and just use the CCR without using TST.

Originally Posted by litwr

Of course, for the code density 68000 relative jumps can be better sometimes. However 8086 can use sometime 2 bytes for such jumps, in a 16-bit jump case it is still only 5 bytes.

The 5 byte case is 80386 in 32-bit mode, for 8086 it's 4.
The situation is exactly the same on the 2 for short branches.

Originally Posted by litwr

@meynaf, thank you very much for your 68000 shortcomings list.

Now if you want to be intellectually honest, it's your turn to write your 80x86 shortcoming list

[meynaf]

Originally Posted by litwr

It is an interesting challenge but 100-200 instructions of high optimized code can require more than a day. I am ready to this contest only if we limit ourselves to no more than 50 instructions.

Still ready for the contest ?
I have an idea. Bresenham line draw routine. Quite a classical algo i guess.

My 68k version will take d1-d2=pos, d3=pixel color, d4-d5=offset (diffs from new coord). You're free to choose which x86 regs you're gonna use. You may even use the stack for parameters if you prefer.
Only thing - routine must not alter the caller's registers so you have to save the ones you use, 'xcept the position (here d1-d2) which need to be updated upon exit (else it wouldn't be fun).

Can/must call external (= does not need to be written here), set single pixel routine (d1-d2=x,y, d3=color) - but which is assumed to be located close enough for short call/jsr.

Is that ok ? It's straightforward, simple routine.

[roondar]

Originally Posted by litwr

Sorry if you have understood it in this way. The spirit of my humble work is in a cliche words "nothing is perfect". 68000 has its shortcomings so as 8086. IMHO 68000 looks like a boxer with very strong right arm but with artificially mutilated left arm. 8086 is more balanced and healthy. Yet again I repeat it is MHO only.

I'm sorry, but this proves my point - you're using your personal (and IMHO not completely fact-based) opinion about which is best as a defence for your article, which 'shockingly' primarily echoes your opinion. This is the definition of biased

Why people try to compare x86 and 68k here? Let's talk about them separately. It is not about what is the best thing. All things in this world have their flaws.

This has happened mainly because this thread is about your article, which does just that. If you didn't want such a discussion, perhaps not write a 68k vs x86 article and then post it into a pro-68k forum

roondar, thank you very much about mentioning x86 interrupt bug. Could you be a bit more specific? Any links will be greatly appreciated. That bug sounds very serious but it contradicts the fact that tens millions of 8086/8088/80286 PCs which were used with it...

Sure, here are some links showing the two different problems with 8086 interrupts. Both where fixed later and both had workarounds.

The video is particularly interesting as it shows the problem in action.

https://blogs.msdn.microsoft.com/lar...-old-cpu-bugs/
http://www.vcfed.org/forum/archive/i...p/t-41453.html
[ Show youtube player ]

I think you underestimate 6502. It can be very fast with byte manipulations, control structures, boolean data, ... Try to imagine, for example, a loop which has to add 77 to each byte in 4 KB byte array. 6502 @2MHz can beat 68000 @8MHz here. Indeed 16/32-bit arithmetic is faster with 68000 and division is much faster.

Well, I decided to take that challenge and wrote a little bit of 6502 and 68000 code doing just that. I even wrote it twice: once using a pretty run of the mill, not extremely optimised bit of code and once unrolling the entire thing (yeah - 4096 add.b's...)

To save some space, I've attached the code and cycle counts to this post as a text file.

Here's the results, where all cycles have been converted to 8Mhz cycles (i.e. the 2Mhz 6502 cycle count has been multiplied by 4):

6502@2MHz vs 68000@8MHz
Adding 77 to each byte in a 4k array (no rippling carry)

Normal code:
6502  - 279304 8MHz cycles
68000 -  90418 8MHz cycles - 68000 is 3.1x faster
Fully unrolled code:
6502  - 163840 8MHz cycles
68000 -  49164 8MHz cycles - 68000 is 3.3x faster

Note that in both cases the 68000 code is both clearly faster and takes up less space. Also note that even a minor tweak (changing it to adding 277 to a each word in an array of 4k) effectively doubles the difference. My point stands, the 68k does much better at complicated code than the 6502.

Thank you for the benchmark link. However it confirms my point that 68000 is generally a bit faster than 8086 and about 50% slower than 80286. Let's see the best values for each CPU.

Indeed. That will definitely help your case. Let's see...
The best posted values for the 8086, 286 and 68000 in that document were:

IBM PC/XT  8086-9.54Mhz    980  980
IBM PC/STD 80286-8Mhz     1724 1785
WICAT PB   68000-12.5Mhz: 1780 2233

Whoops!

But my point here was (and you apparently missed this) that there is huge variation - even at the same clock speed. The fastest 68k ran at 12.5Mhz, yet the Plexus P/60 MC68000-12.5Mhz, which also ran at 12.5MHz only managed a score of 1111 and 1163. Similar things can be spotted for all the CPU's in that table - there are a whole bunch of different results even for systems running at the exact same clock speed. To me this proves that using 1980's benchmarks to try and see which computer is fastest is a really bad idea.

Sorry but I can't still get any fact that contradicts the content of the article. I have some personal points of view only.

I've given you at least one indisputable fact several times by now. Let me repeat it:

"Even the address registers, while seemingly superior to the 8086 segment registers, have a number of annoying disadvantages. For example, they needed to load as much as 4 bytes instead of two for 8086 and of these four, one was extra."

This is false. The move.w <ea>,An command lets you load in two bytes into an address register instead of four. You do not need to load 4 bytes at a time into an address register on 68000. This has been pointed out by me and others. Several times.

Indeed relative jumps at 8086 or even 80286 are poor point but 8088/8086 executes one branch jump for 4/16 clocks (10 on average) and 68000 for 12/18 cycles (15 on average). 80286 requires only 3/7-11 (6 on average) in this case.

The 68000 cycles counts you mention are incorrect:

instruction    displacement   branch   branch
                           taken    not taken
Bcc         byte           10(2/0)   8(1/0)
            word           10(2/0)  12(1/0)
BRA         byte           10(2/0)
            word           10(2/0)

The 68000 takes 8-12 cycles for a branch, average of 10.

[Megol]

An IBM XT with not only a 8086 but one at 9.54MHz? I think that isn't correct, really sure about that in fact.

The XT had a 4.77MHz 8088 and the next step in the lower segment of x86 was a PS/2 model with an 8MHz 8086. It could be a clone however then it wasn't an IBM machine at all.

[Paulee_Bow]

Daddy, Why is everyone arguing about processors that are over 30 years old?