[matthey]

Originally Posted by meynaf

Using address registers to hold data is perfectly possible.

It is a drawback of the 68k that the separation between An and Dn registers is so hard. It was a design decision for the 68000 that separate register files would provide better performance. However, the 68020+ used a monolithic register file and many of the arbitrary barriers were never lifted even though the encodings are often available and would reduce unnecessary data movement (my 68kF ISA shows it would be practical to open up An sources in most instructions while An destinations are more complex and less consistent). The 68k still had 16 registers to the x86 8 registers so it is not like the 68k was at a disadvantage here. There is a little bit to learn about the 68k register division and the auto sign extension but it can be useful and saves encoding bits as you pointed out. Many of those RISC code compressions like Thumb (and others I listed in the other thread) dropped back to 8 GP registers because 3 encoding bits was the most encoding efficient found (immediate sizes were often reduced like 68k quick instructions also). The RISC code compressions tend to have access to less registers with more restrictions than the 68k while providing less code density. How diabolically ingenious to create something that is less than what you started with while getting paid all the way (CISC->RISC->RISC code compression).

Originally Posted by meynaf

But they are not the same. Arithmetic shift sets overflow bit, where logical shift does not.

Yep, the 68k designers did it right.

Originally Posted by meynaf

With two carries you can perform tests and comparisons without deleting carry for next ADDX/SUBX.
Having two carries is odd but it's not an annoyance.
Next oddity, please.

It is helpful because most 68k instructions set the CCR flags. Setting the CCR flags is very good for code density but adds small challenges for CPU design and compiler code generation (some of the problems are due to the 68k being unusual in this regard).

Originally Posted by meynaf

And Moto's ISA can do ADD.W (A0)+,D0 while Intel's ISA just can't.
We can even do MOVE.B (A0)+,-(A1) and x86 can't.
Of course 68k can move memory to memory with any addressing modes.

The 68k is king of the personal computer addressing modes. The powerful addressing modes were its biggest strength and its biggest weakness. The problem was the 68020 ISA adding too complex of addressing modes many of which have little performance advantage and/or are not commonly enough used. Many of these addressing modes are more useful today with OOP languages like C++ and many of the implementation problems back in the day are less of a problem in a modern CPU.

Originally Posted by meynaf

Sure you never wrote a disassembler for x86 (who could do that anyway ?).

You have a disassembler project too?

Originally Posted by meynaf

Some languages such as cobol used bcd quite a lot. So it had some sense.

My father told me I would have to learn COBOL (as I was learning C and 68k assembler) if I was serious about computers. How code has changed. Not just languages but datatypes changed too. Back in the '80s an int was usually 8 or 16 bits and now it is usually 32 or 64 bits. Compressed 32 bit immediates were unnecessary on the 68k then but would be quite helpful for code density today. Those 64 bit CPUs don't seem to worry about all the extra ICache and DCache misses as they just keep adding more caches (now more caches than the '80s computers had main memory).

Originally Posted by meynaf

The fact individual instructions can do a lot does not mean this whole bunch is really useful. Try to write a big enough program with ARM and you will see the opposite situation.
Btw do you have ARM assembly for your pi calculation program ?

He lists the ARM Evaluation System on his web site.

http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html

The code density was mediocre but the performance was good for 1986.