View Single Post
Old 02 April 2015, 18:00   #21
Registered User
Join Date: Jan 2010
Location: Kansas
Posts: 876
Originally Posted by Megol View Post
Any idea how the extra integer registers are encoded? I've asked Gunnar however never got any relevant answer. :/
I'm an "outsider" since I refused to come up with encodings for his extra registers so I don't know for sure. A8 at one point used mostly addressing mode tricks to achieve. The last 3 addressing modes below were undefined on the 68k and may look something like the following.

111 000
(xxx).L 111 001
(d16,PC) 111 010
111 011
111 011
111 011
#<data>.Size 111 100
111 101
MOVE.L <ea>,A8 111
MOVE.L A8,<ea> 111

I'm not sure what other tricks he planned to use for (d16,A8) and possibly (d8,A8,Dn) addressing modes. The last he talked about, only a few addressing modes were supported and this register was called BR (Base Register). I would have preferred he left it as BR that call it A8 as it is less orthogonal that A7. We also looked at creating a new stack register and a base register or 2 base registers.

E0-E7 (originally D8-D15) originally used the Address register EA field in some instructions and then had a bunch of new instruction encodings in whatever encoding hole is available to give functionality close to the original data registers (MVS/MVZ were dropped at one point for MOVEQ #d8,En). Of course these registers are still not orthogonal so compilers can't use them as 8 more data registers. At least Gunnar changed the name from D8-D15.

I wasn't completely opposed to having new integer registers in the CPU but I didn't think they were consistently encoded or orthogonal enough to add to the ISA. Gunnar didn't have a complete proposal worked out either but wanted meynaf and me to help with new encodings for En. When we chose not to participate, we became "outsiders". Of course I had previously done a proposal to add 8 more FPU registers which can be done in a consistent and orthogonal way other than FMOVEM but I would prefer to make all 8 new registers scratch registers with a new ABI.

Originally Posted by jbenam View Post
IMHO the first target should be 100% (or at least 98%) compatibility with old hardware.
I agree. Even Gunnar's ISA should have good compatibility until his enhancements are turned on (requires patches and enhancements to AmigaOS and AROS).

Originally Posted by jbenam View Post
Creating a new ISA/Enhanced Architecture (even if it's fast as heck) will just fragment even more the market and only a small fraction of the users out there would end up using it.
That is the great debate. An ISA only used by Apollo processors would fragment but also give a small to moderate increase in speed (big increase in some code like floating point). A simple and more open standard ISA could be adapted to the TG68 and UAE also. You can argue that there would still be fragmentation but the majority of users could use the standard ISA which offers faster and smaller programs. Is it more important to have extra speed for relatively slow FPGA processors or a common code base (we already have the 68000/68020 split)?

Originally Posted by jbenam View Post
If the Minimig required stuff especially compiled for it, you can bet whatever you want that it'd have bombed massively.

No one is going to spend money and time to support something only a niche of a niche would use.
MiniMig didn't offer as much advancement and Apollo should be mostly compatible out of the box. An Apollo only ISA would be a niche of a niche which I don't think developers would fully support. A simpler standard ISA would only be niche but I think would be supported by developers (I would) even if it's success would still depend on popularity and not be guaranteed. The majority of active Amiga users (including more new users) could be using a new standard ISA if the Apollo, TG68 and UAE added support for the same standard ISA.

Originally Posted by alexh View Post
Should you not have given Chaos the benefit of the doubt?
Are you assuming that copying the FPGA Arcade AGA code would be bad? It's open source so could not have been stolen and Mist (open source) AGA would be even farther along now. I don't see anything negative if Chaos had used the FPGA Arcade AGA code. It is more impressive that he wrote Mist AGA based on MiniMig ECS (I have no reason to doubt what he has said) but it is unfortunately based on older sources which forced him to reinvent the wheel.

Last edited by matthey; 02 April 2015 at 18:06.
matthey is offline  
AdSense AdSense  
Page generated in 0.06961 seconds with 9 queries