Is there something about those [ColdFire] instructions that just totally sucks?
If I would have had those coldfire instructions available to me in the 1980s, 1990s and 2000s then I would have used them and had faster code. But I have put no thought into them at all for around 10 years.
Does Gunnar have a logical reason to murder the coldfire instructions? Like they were stupid instructions? Or they were to slow? Or they bog down his ALU? Or they consume to many read/write ports? Or ?
The only thing wrong with the ColdFire instructions is the ColdFire naming conventions which are not friendly, consistent or 68k like. The solution I came up with are 68k names with ColdFire aliases:
mvs.b -> sxtb.l (Sign eXtend Byte . Long)
mvs.w -> sxtw.l (Sign eXtend Word . Long)
mvz.b -> zxtb.l (Zero eXtend Byte . Long)
mvz.w -> zxtw.l (Zero eXtend Word . Long)
This 68k already has EXTB.L so SXT[B/W].L and ZXT[B/W].L are only a small variation. There is some other minor massaging here and therer. These instructions are quite valuable as they reduce the number of instructions, improve code density, allow for ColdFire compatibility, make x86 emulation easier, allow peephole optimizations in assemblers like vasm and are almost as easy to implement in compiler backends where they already exist for the ColdFire. Gunnar doesn't have anything against them but needed the encoding space and more to encode his non-orthogonal En registers (originally he called them D8-D15 which is even worse having a bunch of non-orthogal registers as data registers; A8 is bad enough).
The A-line extension to NOT clash with ATARI or APPLE or any other old A-line usage.
Matt what you say is just technically not true. You should know this better.
I didn't say you used A-line but rather that was one of your other options which you most certainly were considering (and from your reaction may have used). The 68k MacOS uses A-line for OS function calls as can clearly be seen in MacOS disassemblies:
196: 4268 0004 'Bh..' CLR 4(A0)
19A: 4228 0006 'B(..' CLR.B 6(A0)
19E: 4228 0007 'B(..' CLR.B 7(A0)
1A2: 43FA 036E 1000512 LEA data2,A1 ; len= 1
1A6: 45E8 0009 'E...' LEA 9(A0),A2
1AA: 4EBA 0392 100053E JSR proc2
1AE: 43FA 03A2 1000552 LEA data4,A1 ; 'Multi'
1B2: 4EBA 038A 100053E JSR proc2
1B6: 43FA 03AC 1000564 LEA data7,A1 ; len= 2
1BA: 4EBA 0382 100053E JSR proc2
1BE: 4A6E FFEC 200FFEC TST vab_2(A6)
1C2: 6756 100021A BEQ.S lab_13
1C4: 4FEF FFFE 'O...' LEA -2(A7),A7
1C8: 2F2E FFEE 200FFEE PUSH.L vab_3(A6)
1CC: 4EBA 2C88 1002E56 JSR proc29
1D0: 301F '0.' POP D0
1D2: 6646 100021A BNE.S lab_13
1D4: 4FEF FFCE 'O...' LEA -50(A7),A7
1D8: 204F ' O' MOVEA.L A7,A0
1DA: 317C FFF6 0018 '1|....' MOVE #$FFF6,ioCRefNum(A0)
1E0: 216E FFEE 001E 200FFEE MOVE.L vab_3(A6),ioSEBlkPtr(A0)
1E6: 317C 00FC 001A '1|....' MOVE #252,CSCode(A0)
1EC: A004 '..' _Control ; (A0|IOPB:ParamBlockRec):D0\OSErr
1EE: 4FEF 0032 'O..2' LEA 50(A7),A7
1F2: 206E FFEE 200FFEE MOVEA.L vab_3(A6),A0
1F6: A01F '..' _DisposPtr ; (A0/p:Ptr)
1F8: 486D FFFC -4 PEA glob1(A5)
1FC: A86E '.n' _InitGraf ; (globalPtr:Ptr)
1FE: A8FE '..' _InitFonts
200: A912 '..' _InitWindows
202: A9CC '..' _TeInit
204: 42A7 'B.' CLR.L -(A7)
206: A97B '.{' _InitDialogs ; (resumeProc:ProcPtr)
208: A850 '.P' _InitCursor
20A: 42B8 0A6C $A6C CLR.L DeskHook
20E: 487A 0302 1000512 PEA data2 ; len= 1
212: 4EBA 3198 10033AC JSR PUTREGISTERDLOG
216: 4EFA 0316 100052E JMP com_2
21A: 4227 'B'' lab_13 CLR.B -(A7)
21C: A99B '..' _SetResLoad ; (AutoLoad:BOOLEAN)
21E: 42A7 'B.' CLR.L -(A7)
220: 2F3C 4452 5652 '/ 226: 487A 2156 100237E PEA data35 ; len= 12
22A: A9A1 '..' _GetNamedResource ; (theType:ResType; name:Str255):Handle
22C: 1F3C 0001 '.<..' PUSH.B #1
230: A99B '..' _SetResLoad ; (AutoLoad:BOOLEAN)
The Atari and Sega Genenis may only use TRAP but the x68000 looks like it uses F-line for some OS calls which is not allowed in the 68k ISA documentation as A-line is. I don't know how the Neo-Geo calls functions. Of course ColdFire does not reserve A-line (it is not 68k) and placed MOV3Q in there which is one of the few 68k ColdFire incompatibilities.
Also you did say that the FPGA Vector implementation would prevent an ASIC version of the core.
As the way the Registerfile they way Apollo does it would not be good fro ASICS.
Again that is technically not true.
Technically it should be possible to make an ASIC with a combined vector and integer unit but nobody is going to make an ASIC out of such a screwed up CPU with such a screwed up ISA. It also may be more difficult to create an ASIC out of a ultra-optimized FPGA core all jumbled together.
Matt, we are very happy to discuss compiler optimizations ideas.
Technical ASIC/FPGA discussions should be done by people understanding them fully.
You are overbearing and dominate the "technical" decision making. I know enough about ISAs to know that you have chosen a radical ISA (see the Natami link above where you called more registers a "major ISA change") for a conservative maket which is all wrong. You had 25% support (including you so less excluding you) for more registers and your "major ISA changes". How are you going to get people to use something the majority doesn't support? Your ISA needs major work in compiler backends but how are are you going to gain support for an FPGA CPU with a few hundred users? Even if you were to overcome these large obstacles then how do you plan to compete against hard processors even with the extra registers? My ASIC plan is more feasible than your radical FPGA ISA. An ASIC isn't that expensive and raising money for what people want and like is a lot easier than trying to sell them what they don't want.
The Raspberry Pi is cheap because it is based on an existing cheap SoC that could realistically be produced in quantities of millions of units for less esoteric purposes than as a replacement for a legacy CPU.
An Amiga Cherry Pi (I like cherry better) would have to be a SoC ASIC to be close to as cheap as the Raspberry Pi. It would be difficult to compete with the Raspberry Pi in price and energy efficiency. I would rather target a DVD (optionally Blu-ray DVD) player box kind of like the old PS2 (which is way better than a cheap CD32) but with a removable DVD drive and more expandable (usb, ethernet, wifi, etc,). I think an ASIC enchanced 68k could play HD movies no problem. I would include an FPGA like a Cyclone V which could be used for emulation, acceleration of some tasks, and for embedded uses. It would eventually be able to emulate whatever gaming CD is placed in the drive up to a PS2. Keep everything open so people can use an internet browser (which still can't be done on the PS3). Using the AmigaOS or AROS 68k, 1GB of memory should be plenty. I would aim for a price of $100-200. We would probably need to sell 40k units. I wonder if there were that many people on the Natami forum in it's prime when it generated 300,000+ hits in one thread.
In 2009, gunnar von boehn promised NatAmi with a cpu many times faster than any ppc used in Amiga and with graphics better than PlayStation 3.
I recall a target of PS2 level performance and faster than a 68060. I believe Gunnar has delivered on the latter and had limited control of the former (I don't believe Gunnar can take all the blame for the hibernation of Natami).
That's all for less than 100 euros.
I didn't ever see anything close to this price although it's possible that someone was wishing for this price.
Then every spring NatAmi team promised that this summer Natami will be produced.
I don't recall any promises like this but there were a lot of expectations like this.
Now it is 2015 and there is still nothing.
gunnar where is my NatAmi?
I want my Natami too. Gunnar has the FPGA core that was needed to lower the cost of Natami mostly working and with good performance. Thomas Hirsch knows about it. Some people have different ideas about what team work and cooperation are though.