68k details

[ross]

Every time I read this things, I wonder if in fact the writer has ever really programmed on these architectures...

Originally Posted by litwr

"The CLR problem is implementation bug and has nothing to do with the ISA's quality." Users of 68000 were forced to use CPU with this bug and they didn't have an alternative to use a corrected CPU.

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).

"Address registers don't need to load 4 bytes (not always)." I don't understand this. If we want to set up an address register we have to load 4 bytes into it - and there is no alternative.

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

"bare 68000 is still faster than 80286" It sounds as a complete oddity for me. Try to find out benchmarks of the 80s - it shows that PC XT with 8088 @4.77 MHGz is faster than Mac with 68000, and even 6502 @2MHz could beat 68000 at effective 6 MHz. 80286 is 3-4 times faster than 8088.

These comparisons are totally stupid, they compare the speed of individual instructions or small loops.
As meynaf has written a thousand times we must consider the algorithms in their complexity.
More the code size increases, more the density increases for 68k compared to others.
And the breaking point is reached really really soon.

And yes, I have deeply coded, both for hobby and for work, in all the mentioned architectures and many others.
I'll let you guess which one is my favorite..

Cheers

[chb]

double post, please ignore

[frank_b]

How far can you conditionally branch in a 68k vs an 8086? It's +-32k on the 68k vs +-127 bytes (yikes) on the 8086.

Here are some other interesting questions.

How many registers do you have on the 8086? How many of them can be used for any operation? How many addressing modes do you have? What's the maximum word size you can use? What's the maximum addressing range? How many bits can you shift in a single instruction?

The 8086 is a toy in comparison to the 68k. Like a z80 with delusions of grandeur. You can't compare them. The 68k is superior in every single way.

[roondar]

Originally Posted by litwr

"The CLR problem is implementation bug and has nothing to do with the ISA's quality." Users of 68000 were forced to use CPU with this bug and they didn't have an alternative to use a corrected CPU.

The bug was fixed for the 68020 onwards. Besides, it’s not like there are no bugs in the 8086.

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.

"Address registers don't need to load 4 bytes (not always)." I don't understand this. If we want to set up an address register we have to load 4 bytes into it - and there is no alternative.

This is false.
Both move.w <ea>,An and move.<any> <ea>,address.w exist on 68000.

"bare 68000 is still faster than 80286" It sounds as a complete oddity for me. Try to find out benchmarks of the 80s, for example, https://archive.org/stream/byte-maga.../n247/mode/2up - it shows that PC XT with 8088 @4.77 MHGz is faster than Mac with 68000, and even 6502 @2MHz could beat 68000 at effective 6 MHz. 80286 is 3-4 times faster than 8088.

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.

A silly, but prudent, example here: I used to be really into Mandelbrot rendering back in the day. I had a Simons Basic version on the C64 (1 MHz 6502). I translated this to AMOS basic on the Amiga.

The C64 version took 3,5 hours to finish. The AMOS version took less than 10 minutes. Doubling the 6502’s speed would not have made up for this difference.

This is just a single example, but it’s very easy to find many, many more.



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.

This problem still exists today. Benchmarking is hard to do.

"Actually, one of the worse." My story is an emotional one so I have just expressed my feelings. I like 68000 too but I like truth and facts much more.

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.

EDIT. "There are relative modes, especially 16-bit PC-relative mode which x86 lacks." Those modes can help to make more compact and fast object file code but they mean not much for the executing code. x86 has relative jumps...

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.

[Megol]

Originally Posted by frank_b

How far can you conditionally branch in a 68k vs an 8086? It's +-32k on the 68k vs +-127 bytes (yikes) on the 8086.

Fixed in 1982 but yes.

Here are some other interesting questions.

How many registers do you have on the 8086? How many of them can be used for any operation? How many addressing modes do you have? What's the maximum word size you can use? What's the maximum addressing range? How many bits can you shift in a single instruction?

Counting registers how exactly? 8+4 I'd say.

None. For instance instructions like MOVS*, SCAS*, STOS* use fixed registers. The 8086 is a modified accumulator architecture after all.

Depends on how one counts address modes, is the STOS* instruction an address mode for instance? Not many, I'd say 5.

16 bit of course, it's a 16 bit processor. It does however support some 32 bit operations.

1MiB or 64KiB depending on what you mean.

255(!) - most of those are a waste of time of course. Later x86 limits this, one of the few incompatibilities in the series.

The 8086 is a toy in comparison to the 68k. Like a z80 with delusions of grandeur. You can't compare them. The 68k is superior in every single way.

Nope. Not in price nor complexity. While the 68000 was selected for expensive workstations the 8086 was selected for the IBM PC. The rest is history.

[grond]

Originally Posted by Megol

Nope. Not in price nor complexity. While the 68000 was selected for expensive workstations the 8086 was selected for the IBM PC. The rest is history.

How ironic to think how expensive "serious" computers like the "IBM compatible" were compared to "toy computers" such as the Amiga and Atari...

One thing I would like to mention: there is a reason for the massive preference of academia for the 68k. Between 1985 and 1995 you could hardly find any computer architecture textbook or assembly language course that used the x86 instead of the 68k. It was technically much better than the x86 and only lost to it for economical reasons.

[meynaf]

Originally Posted by litwr

Sorry that some of my points look a bit unoptimal for somebody. However they all are based on my experience and common unbiased facts.

They are not common unbiased facts, as you're alone saying this...
And what about your experience ? If you have experience, then you should have code to show !

Originally Posted by litwr

It is well known fact that x86 family processors still have the best code density.

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

Originally Posted by litwr

I don't know why the code for HOMM2 for x86 could be larger in size than the code for 68000.

Because your claim is wrong ?

You may want to disassemble it maybe ?
I can provide the 68k source, you do the... oh, well - sorry, disassembling something on x86 is a pain in the a$$, i forgot
I only had a partial look at x86 binary, but individual routines i checked were nearly always larger in x86.

Originally Posted by litwr

I can only speculate that the code for x86 was written to support several graphic and sound cards.

Speculation that's irrelevant for the windows version of the binary, and wouldn't be enough to explain an extra 500k.

Originally Posted by litwr

It is also quite possible that x86 version has more maps, etc.

Maps are not embedded in the executable, they are in a separate dir.

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...

But don't worry. x86 ain't so bad ; the Mac PPC version is still a lot larger than the two others

Originally Posted by litwr

A lot of x86 instructions have odd length in bytes, 68000 has to use only even length for any of its instructions - this fact reduces the code density very much.

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.

Originally Posted by litwr

Users of 68000 were forced to use CPU with this bug and they didn't have an alternative to use a corrected CPU.

Neither did x86 users with pentium's fdiv bug nor users of x86 affected by the cmpxchg8b locked on registers (aka F0 0F C7 C8) freeze.
Yes they could wait for next gen cpu but 68000's next gen is 68020 and isn't affected by this.

But most 68000 users didn't even notice !
Because at least CLR on 68000 behaves as expected and the bug did not show on many machines (only on some Amiga's hardware registers), for many it was just a minor timing issue.

Originally Posted by litwr

I don't understand this. If we want to set up an address register we have to load 4 bytes into it - and there is no alternative.

You can load an offset to another address register, or to the program counter, or the stack pointer. In most cases you don't even have to, as you can access the memory directly with d(An) or d(PC) modes.

Anyway, similar story in x86 32 bits, so where's the point ?

Originally Posted by litwr

It sounds as a complete oddity for me. Try to find out benchmarks of the 80s, for example, https://archive.org/stream/byte-maga.../n247/mode/2up - it shows that PC XT with 8088 @4.77 MHGz is faster than Mac with 68000, and even 6502 @2MHz could beat 68000 at effective 6 MHz. 80286 is 3-4 times faster than 8088.

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 :/

Anyway the effective speed of the implementation is of little relevance to me. ISA quality counts better. And while certainly not perfect, the 68k is the only cpu on which serious programs can be coded entirely in asm -- which is not nothing.

Originally Posted by litwr

My story is an emotional one so I have just expressed my feelings.

Indeed.

Originally Posted by litwr

I like 68000 too but I like truth and facts much more. Indeed 68000 is in some way more aesthetic.

If you like truth and facts, only showing real code - and not individual instructions - will do any good.

That said, it's true i don't want to do bare 68000 anymore - which is annoying in some ways - and i code normally for 68030.

Originally Posted by litwr

XADD can be very useful as an atomic operation - https://en.wikipedia.org/wiki/Fetch-and-add

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.

Originally Posted by litwr

You can use OR R,R instead of TST R.

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

Originally Posted by litwr

Those modes can help to make more compact and fast object file code but they mean not much for the executing code. x86 has relative jumps...

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

Originally Posted by jotd

@meynaf: the reset button could get rid of some lockups (where the cursor was still blinking) but not the ones where the CPU was latched, like instruction $02. I didn't think of changing my 6502 to a 65C02 either.

Hmm, maybe i got confused with the jasmin drive's "reset" button, which indeed could get rid of this situation without having to power the oric off...

[Thorham]

Originally Posted by meynaf

68k is the only cpu on which serious programs can be coded entirely in asm

You can write a whole OS in x86: MenuetOS http://menuetos.net/

[meynaf]

Originally Posted by Thorham

You can write a whole OS in x86: MenuetOS http://menuetos.net/

These guys are masochists

Yet it's perhaps not as good as it looks :
- we have no idea about the quality of their API - old MSDOS versions were asm too, after all
- nothing proves it's really handwritten asm ; you can compile something and pretend it's asm (who will check ?)
- very few apps seem to be available
- look in the history to see how much time it took them

[Thorham]

Originally Posted by meynaf

These guys are masochists

I wouldn't know, because I never write x86/x64 code. On the peecee I use C# (and C sometimes).

Originally Posted by meynaf

nothing proves it's really handwritten asm ; you can compile something and pretend it's asm (who will check ?)

I highly doubt that's the case here, because what's the point?

[Megol]

Originally Posted by grond

How ironic to think how expensive "serious" computers like the "IBM compatible" were compared to "toy computers" such as the Amiga and Atari...

Don't forget that the IBM PC came to market 4 years before the Amiga 1000 - an expensive system - and 6 years before the more affordable Amiga 500.

One thing I would like to mention: there is a reason for the massive preference of academia for the 68k. Between 1985 and 1995 you could hardly find any computer architecture textbook or assembly language course that used the x86 instead of the 68k. It was technically much better than the x86 and only lost to it for economical reasons.

Yes? That's obvious, the 68000 is more comparable with the mainframe IBM 360/370 system than microcontrollers and other microprocessors at the time. In fact IBM used a modified 68000 as a micro-mainframe for some computer. A nice relatively clean design easy to describe and program.

The 8086 is also easy to program, there are generally only one way to do things. Generating near optimal code for it can be done in a simple one pass compiler, that's how cookie-cutter code friendly it is. Limiting but easy.

--

Read the linked posts in the OP and... I thought meynaf was going about as usual (can't say anything remotely bad about 68k or remotely good about any other architecture to that man) but here I have to agree.

The 8086 vs the 68000 have only one winner architecturally, the 68k. X86 could only start to compare with the 80386 which is a massive reinvention of the basic modified accumulator design to an almost fully orthogonal register design - the keyword is MASSIVE.

[grond]

Originally Posted by Megol

Don't forget that the IBM PC came to market 4 years before the Amiga 1000 - an expensive system - and 6 years before the more affordable Amiga 500.

Yes, I know and agree for the most part. Nonetheless it is interesting to see. I think that the Amiga was superior to the PC until the advent of the 386. And many aspects of the PC continued to be ridiculously inferior. If we compare the costs of a 386 with soundblaster and a reasonable soundcard, I'm pretty sure that it was much more expensive than a comparable Amiga. A friend of mine had such a 386 system and it had cost 8000 DM. The Amiga 1000 preceded that system and cost 5000 DM.

The 8086 vs the 68000 have only one winner architecturally, the 68k. X86 could only start to compare with the 80386 ...

Yes, I think we can all agree to that.

[meynaf]

Originally Posted by Thorham

I highly doubt that's the case here, because what's the point?

What's the point in writing an OS with so few apps ? I don't see any, but they did.
What's the point in lying about it being real asm ? I remember some old 8-bit game advertised as 100% asm, which was mostly encrypted Basic program...

The fact they don't provide the sources for download is at least suspicious to me. It looks so incredible.

Originally Posted by Megol

Read the linked posts in the OP and... I thought meynaf was going about as usual (can't say anything remotely bad about 68k or remotely good about any other architecture to that man) but here I have to agree.

The fact is that as an asm programmer i can say good things only about architectures that are designed for that.
And while I may say a lot more bad things about 68k than you imagine, what would be the point ?

[britelite]

Originally Posted by meynaf

The fact they don't provide the sources for download is at least suspicious to me. It looks so incredible.

At least the sources for the 32bit version are available for download. Not that it will convince you anyway...

[roondar]

Originally Posted by meynaf

What's the point in writing an OS with so few apps ? I don't see any, but they did.

After reading an interview with the creators (https://www.goodgearguide.com.au/art...mbly_language/), it seems to me that the OS was made to scratch the developer's personal itch and is mostly a hobby. A very odd one perhaps, but still.

It's kind of like asking "What's the point in writing new Amiga software in 2018" or "What's the point in making a painting in the style of Vincent van Gogh" - the same answer applies: because the person doing so wants to do it

[Thorham]

Originally Posted by meynaf

What's the point in writing an OS with so few apps ? I don't see any, but they did.

The challenge? For fun? Academic practice?

Originally Posted by meynaf

What's the point in lying about it being real asm ? I remember some old 8-bit game advertised as 100% asm, which was mostly encrypted Basic program...

If that game is commercial than the reason for lying is obvious, but this OS isn't commercial, so they have no reason to, apart from people saying how crazy they must be for writing an OS in asm.

Originally Posted by meynaf

The fact they don't provide the sources for download is at least suspicious to me. It looks so incredible.

It's not all that incredible. It's perhaps more work than writing a similar OS in 68k, but if people can manage to get to the moon in 1969, then writing an OS in x86 asm seems like easy cakes

Originally Posted by meynaf

And while I may say a lot more bad things about 68k than you imagine, what would be the point ?

Could be interesting to hear!

[meynaf]

Originally Posted by britelite

At least the sources for the 32bit version are available for download. Not that it will convince you anyway...

Available for download, huh ? And... where ?

Originally Posted by Thorham

The challenge? For fun? Academic practice?

That's nothing worth so much touble...

Originally Posted by Thorham

If that game is commercial than the reason for lying is obvious, but this OS isn't commercial, so they have no reason to, apart from people saying how crazy they must be for writing an OS in asm.

There are so many fakes for so many things in the internet, so why not that ?

Originally Posted by Thorham

It's not all that incredible. It's perhaps more work than writing a similar OS in 68k, but if people can manage to get to the moon in 1969, then writing an OS in x86 asm seems like easy cakes

Yes but it depends how far you push the concept of "OS". If it's just some odd kernel running on a very limited set of machines, with very few APIs and next to zero apps, then yes it's possible.

Originally Posted by Thorham

Could be interesting to hear!

You *do* want the list, hmm ?

A few have been mentioned here already if you paid attention to them, but here are a few annoyances (nothing close to the horror it is on other cpu families, obviously) :
. no eor from mem
. no exg in mem
. two carries (as i said, minor, but nevertheless valid, shortcoming)
. code density could have been better, especially with immediates
. 020+ strange modes (more problematic for the implementation though)
. addressing modes missing from movem
. lack of flexibility for address registers
. a7 shouldn't have been sp
. duplicate encodings for same operation (add #i vs addi)
. pc-relative modes not writeable (even though i know the design reason for this)
. lack of flexibility for shift operations
. ipl=0 is exact same as ipl=1 (not an annoyance but an oddity)
. vector table not exactly clean and compact
. stack frame incompatibility over members of the family
. no byte index, but nothing to ease extending values either
. strange compatibility tricks : move ccr, byte push/pop doing a7 +2/-2
. dbf limited to 0..n and word size
. many instructions needlessly touch the ccr (or some bits of it)

And of course it's not difficult to "invent" extra instructions that would be quite practical to have.

@Megol: seems you were wrong when you wrote i just can't say anything remotely bad about 68k.

[britelite]

Originally Posted by meynaf

Available for download, huh ? And... where ?

Right here: http://www.menuetos.net/M32.htm

[meynaf]

Originally Posted by britelite

Right here: http://www.menuetos.net/M32.htm

Finally !
So it appears to be real asm.
Well, but that's not exactly "a whole OS", rather a small vm.

So what does it prove ? That with 10-15 years one can write something that remotely resembles an OS ? How long did it take for Sassenrath to write Exec ?

[Leffmann]

Meynaf, you're drunk. Turn the computer off and go to bed.