68k details

[NorthWay]

Originally Posted by NorthWay

Talking to myself, but some groundwork has been done over at http://www.visual6502.org/images/pag...ola_68000.html

Googling is fun. See https://seanriddle.com/scn68000c8n64.html

And I'm pretty sure I passed by one of the Atari forums where they were talking about a decode and had a file of the microcode along with a description of the long form opcodes that the internal microcode was executing.
Oh, and somewhere I read that you could futz some of the physical pins to make it dump out its internal microcode!

[litwr]

I'm very sorry for a big delay. At first I should inform that I have just added a new sentence to my article;

But the information about the code density is controversial – there are some points showing that in some cases 68000 could have better code density.

I have also published parts about ARM (https://litwr.livejournal.com/2509.html) and VAX-11 (https://litwr.livejournal.com/2286.html).

Originally Posted by meynaf

Only SI can read with auto-increment.
Only DI can write with auto-increment.
Only DX can be used as loop counter with the loop instruction.

I can repeat again it is wrong. SI and DI can be always used with auto-decrement as well. DX is never used as a loop coiunter.

Originally Posted by meynaf

Not eager to get it, huh ? I won't wait any longer and have made the upload anyway. Other ppl might be interested.

I have got "litwr, you do not have permission to access this page." So you evaded to show your code. I'm sure that there is something wrong with it.

[Galahad/FLT]

Originally Posted by litwr

I have got "litwr, you do not have permission to access this page." So you evaded to show your code. I'm sure that there is something wrong with it.

I'll be very polite, especially when your response to Meynaf is very rude.

1). Meynaf clearly showed you how to get access to "the zone".

2). Meynaf clearly uploaded the file to the zone inspite of your no show.

3). The file Meynaf is STILL there in the zone, the instructions Meynaf gave you to get access to the zone is STILL there in THIS thread on page 25

Your SELECTIVE reading doesn't do you any favours.

Go look again!

[litwr]

Originally Posted by Galahad/FLT

I'll be very polite, especially when your response to Meynaf is very rude.

1). Meynaf clearly showed you how to get access to "the zone".

2). Meynaf clearly uploaded the file to the zone inspite of your no show.

3). The file Meynaf is STILL there in the zone, the instructions Meynaf gave you to get access to the zone is STILL there in THIS thread on page 25

Your SELECTIVE reading doesn't do you any favours.

Go look again!

Please excuse me I am a bit busy these days. Sorry I had missed the instructions. Dear Meynaf, I am really sorry. I can only try to justify myself by a reason that it will be easier for me just to get the file directly. I've just got your file but I need more time to process it. However my point was only about 68000 not 68020. Anyway I am impressed that your code for 68020 is a bit shorter than my for 80386. I hope it didn't lose its performance.

[meynaf]

Originally Posted by litwr

I can repeat again it is wrong. SI and DI can be always used with auto-decrement as well. DX is never used as a loop coiunter.

It is not wrong if you read it correctly. I mean SI and DI are the only registers with auto-increment. Same for auto-decrement, obviously.
And yes it's not DX that's used as a loop counter, it's CX. But it does not change the fact you can not choose which register it is !

Originally Posted by litwr

I have got "litwr, you do not have permission to access this page." So you evaded to show your code. I'm sure that there is something wrong with it.

There is probably something wrong with it if you invent new rules
But it has been tested and it works.

If you say there is something unfair with the OS routines i have used, i'll remind you that your x86 code is headerless .COM where Amiga programs have to account for the hunk format data so this compensates that...

Originally Posted by litwr

Please excuse me I am a bit busy these days. Sorry I had missed the instructions. Dear Meynaf, I am really sorry. I can only try to justify myself by a reason that it will be easier for me just to get the file directly. I've just got your file but I need more time to process it.

No problem, but please stop jumping to conclusions too fast

Originally Posted by litwr

However my point was only about 68000 not 68020.

When i speak about 68k i don't speak about 68000 but about the 680x0 family in general. I said several times i don't code much for 68000 anymore. In fact i don't like old 68000.
But anyway pure 68000 code wouldn't be much larger than this one (only mul & div code needs to be changed).

Originally Posted by litwr

Anyway I am impressed that your code for 68020 is a bit shorter than my for 80386. I hope it didn't lose its performance.

Only performance difference that can appear would be due to different OS calls for showing the result...
Else i did not touch the core code, which would be (a little) smaller again if performance wasn't an issue (or if code was written for 68060).

[litwr]

@meynaf Your code is as fast as mine! But you have just replaced i/o-routines for input and output text using high-level Amiga built-in ROM functions - it's not completely fair. I can replace PR0000 and getnum with a slower but lesser in size routines and this gives 80386 the first position again.
It is interesting that when I compile your code with cross-assembler vasm I get a bit different binary file. It has the same size but differs in 3 bytes. It shows again that 68k has too much redundancy in its ISA.
I can resume my point about why 68k lost and Intel and ARM won. 68000 and 68020 has too much redundancy in their ISA, too much complexity. When time was come to convert electronics to the new fast 6502/ARM-like standards it was much more difficult for Motorola with 68k than for Intel with x86. It was not unique. DEC completely abandoned its famous VAX series in the favor of new RISC Alpha because it was impossible to convert electronics of the huge VAX ISA. BTW this conversion is very costly and difficult therefore even today for x86 is faster to execute two instructions DEC CX and JNZ loop, than one LOOP loop. So number of x86 instructions are still not converted for the fast execution. 68k orthogonality gives less flexibility for such maneuvers. Motorola had to move towards PowerPC, because ARM was too fast. It is fascinating that ARM @8MHz could outperform 68030 @25MHz.

[meynaf]

Originally Posted by litwr

@meynaf Your code is as fast as mine! But you have just replaced i/o-routines for input and output text using high-level Amiga built-in ROM functions - it's not completely fair. I can replace PR0000 and getnum with a slower but lesser in size routines and this gives 80386 the first position again.

Use of OS routines is unfair ? But use of headerless .COM (rather than normal .EXE) is also unfair !
Either you allow using OS features or you do not. In either case, 80386 can't get first position.
Also remember all the code that's needed to open libs on the Amiga. Counting that against the 68k is really unfair so don't grumble i used OS functions.

Originally Posted by litwr

It is interesting that when I compile your code with cross-assembler vasm I get a bit different binary file. It has the same size but differs in 3 bytes. It shows again that 68k has too much redundancy in its ISA.

You criticize 68k for it, but in fact 68k has less redundancy in its ISA than x86...

Originally Posted by litwr

I can resume my point about why 68k lost and Intel and ARM won. 68000 and 68020 has too much redundancy in their ISA, too much complexity.

This is not the reason why 68k lost.
Intel won because of the IBM 5150.
Arm won because it's available for everyone to build.

Originally Posted by litwr

When time was come to convert electronics to the new fast 6502/ARM-like standards it was much more difficult for Motorola with 68k than for Intel with x86. It was not unique. DEC completely abandoned its famous VAX series in the favor of new RISC Alpha because it was impossible to convert electronics of the huge VAX ISA.

And now we have huge x86 ISA (around 1300 instructions). So what ?

Originally Posted by litwr

BTW this conversion is very costly and difficult therefore even today for x86 is faster to execute two instructions DEC CX and JNZ loop, than one LOOP loop. So number of x86 instructions are still not converted for the fast execution. 68k orthogonality gives less flexibility for such maneuvers.

Why ? You can replace DBRA by SUBQ/BCC on 68k too.
Actually 68k gives more flexibility for such maneuvers.

Originally Posted by litwr

Motorola had to move towards PowerPC, because ARM was too fast. It is fascinating that ARM @8MHz could outperform 68030 @25MHz.

But 68060 outperforms similar clocked ARM.
And todays x86 outperform todays ARM.
Not to mention it may also be fascinating that ARM @8Mhz could outperform 80386 @25Mhz.
All that is meaningless.

[plasmab]

At the risk of re-igniting a flame war. IMHO ARM won not just because it was available for everyone to build but because of its insanely low power consumption. (Makes it very appealing for mobile)

EDIT: but ARM was stupid until Thumb came along. As much as I love ARM it need far too much RAM.

[litwr]

Originally Posted by meynaf

And now we have huge x86 ISA (around 1300 instructions). So what ?

Things are only good in time. And I have just explained my point, indeed, IBM PC was a factor too. However if Moto had had easier design for 68000 it could have been produced earlier and this might have allowed 68000 to compete with 8088 for the IBM PC.

IMHO COM-file format is quite a fair way to get much code density. It shows the advantages of the segment registers.

[idrougge]

IBM PC was the only factor. Apart from the PC and a few failed school computers (based on 80186), I can't come up with a single design built around the x86. The 68000 was everywhere, from workstations to game consoles, from home computers to print servers, from arcade machines to lab instruments.

[litwr]

Originally Posted by idrougge

IBM PC was the only factor. Apart from the PC and a few failed school computers (based on 80186), I can't come up with a single design built around the x86. The 68000 was everywhere, from workstations to game consoles, from home computers to print servers, from arcade machines to lab instruments.

It sounds contradictory for me. Everybody had been happy with 68k and after a few moments they became unhappy... Why?! I can again say about quite popular Apple Macintosh which could successfully compete with IBM PC. Atari and Amiga had their respectable ecosystems. There was a world of 68k based Unix workstations. So your argument rather contrived for me.
IMHO it is quite natural to consider that ARM began the era of fast processors and Motorola couldn't convert its huge ISA for the new technology fast enough. Motorola wanted to share DEC VAX success in the late 70s but it caused the necessity to share its failure too in the beginning of 90s.
I can repeat Intel and ARM didn't follow DEC or IBM/370 - they just created better processors. On the contrary Motorola and National Semiconductor tried to create a processor with ISA similar to VAX.
BTW computers for Unix also needed something better than 68k so Sun developed its famous SPARC processor for them and became the leader for that market. It didn' use x86 even despite of the presence of a terrible monster "IBM PC".

[meynaf]

Originally Posted by litwr

Things are only good in time. And I have just explained my point, indeed, IBM PC was a factor too. However if Moto had had easier design for 68000 it could have been produced earlier and this might have allowed 68000 to compete with 8088 for the IBM PC.

If they had "easier" design then they would have gotten "poorer" design as well, and it wouldn't have been interesting at all.

Originally Posted by litwr

IMHO COM-file format is quite a fair way to get much code density. It shows the advantages of the segment registers.

No it's just unfair way. Every cpu can have headerless code.
On the 68k we could have shown the advantages of position-independent code, however the OS can't run headerless code directly.
Remove 36 bytes out of the Amiga version you currently have and it beats 386 again doesn't it ?
Besides, a good cpu should have a good OS so using the OS routines for formatting is showing the advantages of a good ISA in comparison to a poor one
Else we have the overhead of opening dos.library and you dare to count that against 68k's code density...

Anyway, perhaps 68k can still beat x86 even with these handicaps you have added (hunk headers, system call overhead, lack of formatting OS routines). I have not removed every possible byte in here, just put it under 600 bytes to show you it was possible...

[Don_Adan]

I dont checked/see meynaf code, but f.e for open dos.library, private open library can be used (12 bytes shortest, if i remember right). I dont think that x86 can has any chance with 68k with code denisty, maybe accidentally only. I see exe from many games for Amiga and PC from 1989 to 1992 years, and always PC exe was bigger, mostly about 50%.

[ross]

Originally Posted by Don_Adan

.., but f.e for open dos.library, private open library can be used (12 bytes shortest, if i remember right).

Hi Don, that I know the only way to open dos.library is using OpenLibrary() [or OldOpenLibrary() for a generic version open with only two bytes saved].
Or maybe exist some obscure BCPL programming practice?

[Don_Adan]

Originally Posted by ross

Hi Don, that I know the only way to open dos.library is using OpenLibrary() [or OldOpenLibrary() for a generic version open with only two bytes saved].
Or maybe exist some obscure BCPL programming practice?

Yes, for ROM 3.0+ exist shortrest (private) version. You can check my resourced version of ROM modules. As input is used moveq #x,D0, but only for some libs it can be used.

Here is example:

Init
	movem.l	D2/D6/D7/A3-A6,-(SP)
	move.l	A6,A5			; exec base
	moveq	#4,D0			; dos library
	jsr	-$32A(A6)		; TaggedOpenLibrary
	move.l	D0,D7			; dos base
	beq.b	Error
	lea	LIBSworkbench.MSG(PC),A0
	move.l	A0,D1
	moveq	#-2,D2
	move.l	D7,A6			; dos base
	jsr	-$54(A6)		; Lock
	move.l	D0,D6
	beq.b	AllocVec
	move.l	D6,D1
	jsr	-$5A(A6)		; UnLock
	move.l	A5,A6
	bra.b	Close

[ross]

Originally Posted by Don_Adan

Yes, for ROM 3.0+ exist shortrest (private) version. You can check my resourced version of ROM modules. As input is used moveq #x,D0, but only for some libs it can be used.

Ok, thanks. So unfortunately is not a general solution .

[Don_Adan]

For dos.library moveq #4,d0 and jsr -$32A(A6).

[Don_Adan]

Originally Posted by ross

Ok, thanks. So unfortunately is not a general solution .

No, this is useful only for ROM 3.0 or higher programs/code. But if for some Amiga assemblers/compilers standard Amiga hunks relocation are short (word) hunks from ROM 3.0 too, then I dont see disadvantages to use this version too. If you assemble your programs with short word relocation, it can be runned only for ROM 3.0 and even you dont need to use ROM check version in your code

[grond]

You are happily mixing technical facts collected from several decades to make your point. All your reasoning relies on inadmissible hindsight.

Originally Posted by litwr

It sounds contradictory for me. Everybody had been happy with 68k and after a few moments they became unhappy...

They had been happy for a whole decade. Pretty long "few moments" if you ask me.

I can again say about quite popular Apple Macintosh which could successfully compete with IBM PC. Atari and Amiga had their respectable ecosystems. There was a world of 68k based Unix workstations. So your argument rather contrived for me.

The 68k could have easily survived and remained superior to the x86 if the same amount of money and manpower had been invested into its development. It is as easy as that. Intel had loads of money from the huge success of the PC and at the same time there was a huge amount of closed-source software that made their customers reluctant to switch the processor platform.

There are no technical reasons why a 68k ISA could not be as fast or faster than the x86 counterpart. In fact, the 060 was a very good competitor to the Pentium and also faster than the first PowerPC processors. The reason why CISC was abandoned was that no other company than Intel could afford the huge R&D effort it took to make the ugly and nonorthogonal ISA that fast. RISC was introduced to make it more economical to develop a processor. Abandoning 68k in favour of the PowerPC ISA was a management-driven decision. There was less legacy-software intertia than in the x86 campus (Apple, after all, was agreeing to the move to PPC) and processor development was becoming cheaper due to moving to a RISC ISA.

Were there needlessly complex parts in the 68k ISA? Yes, of course. Did that mean that the 68k couldn't have been made to compete with x86 performancewise? Heck, no, of course not.

IMHO it is quite natural to consider that ARM began the era of fast processors

There is no such thing as an "era of fast processors". Selecting ARM as the beginning of such an era is totally arbitrary. And frankly, nobody cared for ARM. It is only in hindsight that ARM seems to have been a relevant ISA because it is relevant TODAY. The ARM ISA is not so different from many ISAs of the time. And it suffers from many things that seem very ugly today like predication or the link register. Because ARM is relevant today, many of the shortcomings of the original ARM ISA have been abandoned in the more recent ARM ISA revisions.

and Motorola couldn't convert its huge ISA for the new technology fast enough. Motorola wanted to share DEC VAX success in the late 70s but it caused the necessity to share its failure too in the beginning of 90s.

And why could Intel "convert its huge and nonorthogonal ISA" fast enough? Only because they had the money and thus the manpower. Why did Intel survive the existence of faster processors to begin with? Because of the infamous "PC compatibility" requirement that has held a large proportion of the processor market hostage for some decades. DEC had the Alpha and the PowerPC 604 was also faster than any Intel processors at the same time.

I can repeat Intel and ARM didn't follow DEC or IBM/370 - they just created better processors.

Better than the preceding generation of processors, not necessarily better than the competition. This was enough because of the compatibility lockdown. As long as another processor ISA couldn't emulate x86 fast enough to outperform them, Intel could just go at their own pace. Interestingly Intel themselves failed prominently in marketing a better ISA than x86. Even they could not overcome the compatibility obstacle because providing a faster processor wasn't enough to gain a market.

On the contrary Motorola and National Semiconductor tried to create a processor with ISA similar to VAX.

Again you are happily jumping from one decade of processor development to another...

BTW computers for Unix also needed something better than 68k so Sun developed its famous SPARC processor for them and became the leader for that market.

Yes, and SPARC was superior to x86 until the advent of the Pentium III. As was just about any RISC processor. Those were happy times because there were more than two competing ISAs. That is a good thing and not suitable as an argument against an arbitrarily chosen one among the available architectures. You could just as well say "Sun needed something better than ARM and thus developed its SPARC processor".

[SUN] didn' use x86 even despite of the presence of a terrible monster "IBM PC".

Do you see the point you are making yourself? The x86 survived because of MONEY, not because of any technical superiority. The x86 wasn't suitable for what SUN needed.

Even AMD cannot keep up with Intel even though they are building the same ISA. It's because of the MONEY that only Intel can put into R&D and their fabrication process which is at least one generation ahead of all the competition.

[roondar]

If we're going to be talking about 'happiness' with a particular ISA, it might be interesting to note you can still get brand new (produced in 2018), ROHS compliant 68000's right now. They might be a tad expensive at between 12 and 20ish euro's a piece, but still.

As far as I've been able to find, you can't do that with the Intel 8088/8086. It seems to no longer be produced.

In other words, people are still willing to both make and buy 68000's nearly 40 years after their introduction. Yet no one seems interested in doing the same with the Intel 8086. To me, this is a pretty clear indication the 68000 clearly did something very right - not many tech products get to be sold for such a long time.

And I'd wager this also shows that a lot of people were very happy with the 68000 and successors. If it had failed back in the 1990's, you wouldn't be able to still buy them new today.