in case you are interested to test new fpga accelerators for a600/a500

[OlafS3]

For a long time software for Amiga has come released in more than one version. For example... 68000 and 68020 versions. Wouldn't it be possible for developers to continue this practice with an additional release option for Apollo card owners?  Or am I misunderstanding this part of the discussion?

That being said, how would a compiler deal with new features added to Apollo? In the case of 68K vs 020 versions, it was basically a compiler switch option.

And maybe that second question belongs over at the techie Apollo thread.

Plaz

I am not a compiler developer but I think it would be a added switch

[OlafS3]

Neither - nor. Nor do I have an axe somewhere. The problem when modifying the ISA is the value/price ratio. The value of the above extensions are minimal, the cost is potential software incompatibility, potentially causing a lot of useless support requests for whomever creates software. There are really better ways to spend the ISA space.  

Really, Gunnar and I chat frequently, and friendly. But that still does not mean that one cannot have an argument from time to time. I personally would not extend the ISA in that way, or at least for so little returns.

I think sometimes people problems see where no really is

There will be not only a new core but also a (planned) chipset for the card and both will be in development and change over time. So updating will be required in any case. Affected will be software that directly hits the hardware, applications will (hopefully) only use the OS (f.e. AROS 68k) and thus not be affected at all. Games that are planned to run everywhere will also not be affected. So we talk about certain heavy software like a specific browser version or certain games that might make full use. All old 68k software will not be affected either. As long as it is clear what is added every developer can decide if he wants to use new features or not. And users have to update the FPGA regularly anyway (because of both changes of core and chipset).

[OlafS3]

Very fine then. Why is it then relevant to have new instructions in first place?  Let's check what we have:    

*) LineA: This instruction space is not usable because MacOs has its Os traps here.

*) More data registers, A8: Not usable in a multitasking Os because exec does not save and restore these on a context switch. For support, the exec scheduler had to be drilled up. Possible, but creates problems with monitors and system tools like Xoper and friends that analyze the exec stack frame. Hence, more problems for software developers and users, instead of less.

*) Instructions like "MVZ": Not useful because they can be replaced by a sequence of two instructions without any additional cost. Ok, the code gets two bytes longer. Big deal.

So in the end, there are no benefits or no usable benefits at the cost of compatibility. The question is: Would anyone use these instructions in new code? If so, new code would be required to compiled for the old instruction set, and the new instruction set. So basically, the user has to know on which system the software is to run - or would receive crashes.

Does it make sense to write a CPU-dispatcher in a program for such small benefits? Likely not. I will not add a dispatcher to save two bytes for some instructions (after all, I would have to duplicate code, thus making things longer instead of shorter). I will not use additional registers because they are not saved and restored by exec.

The only thing were I believe some extra instructions are useful are in highly specialized bottleneck-algorithms where it makes sense to have a CPU-specific dispatcher, and two versions of the same code because it makes a noticable speed benefit for the user.



Then why do we need new instructions in first place?

to give the question back... as long as it is (and stays) compatible to existing 68k code (and what is created by compilers) does it harm to add things? Even if most software will not use it? Applications will normally run on the OS, either use AmigaOS 3.X or AROS 68k, only some powerhungry applications like a browser might use some special commands to speed up. Games would theoretical benefit most but again if you want something that runs on different platforms like in emulation you will not use it. Compilers will mostly not support it either (no sources available and/or noone who will add support). So in reality we now have endless discussions about a small minority of programs who might be incompatible because using special commands. You can say it is a waste of resources to implement them (in your view) but it is Gunnar wasting his time and as long as it not harms compatiblity to existing code and compilers it is not a problem to me. Or do I understand something wrong? Can you explain me what are your problems with it and where it hurts? I do not understand it. But I am not a asm coder.

[OlafS3]

Perhaps you just dont understand that yet another community split (produced by a badly designed ISA) will harm the entire Amiga/Amiga-ish systems one more time.

Why badly designed? Because keeping Classic Mac compatibility, and as suggested, adding Coldfire compatibility will surely attract more users and developers to 68k systems, which means better debugging and better testing, more compiler support, and of course, much more market opportunities.

On the contrary, a badly designed ISA will be only interested to a niche inside a niche of programers, and that comes with a lack of proper compiler support (yeah, you will only have assembler). So you will have software that will only benefit very few users and not the entire Amiga/ish ecosystem.

I think what Thomas means is concentrating on existing core (up to 68060) instead of adding new commands. I understand that but I think Gunnar is a engineer and it is his baby. Thomas did not write that the core is not compatible but there is no real concept behind the extensions. I understand it and I already wrote my view. 100% compatibility is mandatory, if the core should be extended beyond that is discutable but that is Gunnars decision. There will be more testers in near future so more reports what works and what not.

[OlafS3]

And WHDLoad runs fine on Phoenix - but WHDLoad and the games it supports also run fine on any Amiga with a bit of RAM already, none of the old games have any use for an improved 68k CPU.

I know that you dislike Gunnar

the people interested in it will buy the cards and then we will see what happens. But no whining if you are not part of it

[OlafS3]

Yeah, I am the one who brought up Mac emulation, both because it is an excellent compatibility test, and because it is usefull as old MacOS still has plenty of software that is unmatched on AmigaOS.

As of right now though, more pressing issue is that reaction applications in OS3.9 apparently do not run on Phoenix yet, so no Prefs. I am curious if latest workbench.library (which is 020+) works.

The FPU is (or rather, is planned to be) from what I understand, not compatible with existing FPUs, so no benefit for old FPU intensive software like Lightwave 3D, Imagine etc.

No MMU, just talks about some sort of new MMU that Thomas for sure will fix OS support for with his libraries, same Thomas who is highly critical about a lot of the design decissions and who has clearly stated he is not interested in supporting new instrictions. Old software requiring MMU, from debuggers to VMM and whatever, will not work.

No backend support in any compilers, I am curious what plans OlafS3 plans to support the new instructions etc with AROS/m68k when he has no gcc that support it.

Talks about how Phoenix will be so fast that compatibility with existing software is of no concern, which begs the question - why not just use ARM or some other more relevant architecture instead?

Talks about "killer apps" and "modern browsers", yet boards crippled with only 128MB of RAM, a lot of unecessary incompatibility, shunning off OS developers as well as compilator developers.

Talks about "an enemy", whoever that may be.

Lack of openness, lack of documentation and design route that seems totally ad-hoc, and attitudes that have shunned away other developers for years already. All this is main reason why Natami never really happened in the first place.

Conclusion? Gunnar seems hellbent on creating his own dream CPU, which is fine. Less fine is that he also seems hellbent on luring the entire Amiga 68k community into his proprietary trap. Yeah right, good luck with that.

So, I'd love to see more open and colaborative people to do a more usefull and compatible m68k softcore. Which brings me back to - who is this enemy the Apollo team is talking of?

"Enemy" it was a ironic comment, humor is not your strong side obviously. You do not pay anything, you are not even forced to buy anything and yet are whining all the time.

BTW what are you talking about? He promises to make it compatible so people can develop without using those features, nobody is forced to get into the "trap". As i said it is only for a minority of software. This project is the only realistic option to get 68k development again. Good luck with finding a FPGA development team. Are you able to do it? Then do it. If not stop moaning. And who says I plan to support this new commands with Aros 68k? I do not really care. They would be at best useful for certain purposes. As long Gunnar does not break compatibility I do not care. Regarding WHDLoad even on UAE many games become unplayable because of speed, Wing Commander as a example. If you are only interested in the old hardware why even bother with new hardware. Then you are best with a old A500. Nothing beats the old hardware. New hardware is for new software. 128 MB has (as i explained several times already but you repeat it again and again) has to do with the concept of using off-the-shelve hardware. Guess how much custom hardware would cost and I know what you would then say. It is compromise but you seem not to understand it.

[OlafS3]

No, that would make the whole situation even worse, not better! The point is exactly *not* to segment the platform. How would another core *help* here? Right, not at all, it would make things worse, not better.

Once again, I have absolutely nothing against Gunnar. Why should I? We chat together from time to time, he's doing a great job, and the FPGA project is probably the most sensible project I've seen in years. Just that it doesn't make sense at this point to segment the platform by introducing new incompatibilities. And your answer is to segment it even more, instead of less?

Segmentation of the Amiga market is the single most dominant problem we have here.   No, another problem created. Thank you - what's so hard to understand here? Any attempt to define a "new platform" is again the license to fail because it again splits the user basis. Even less users... Thank you.

 

No, not all. You just do not understand the argument. It is not technical at all. I am just saying that introducing new instructions without any requirements analysis is a bad move and pretty premature.

I understand what you write but you are a engineer too (as far as I know) so you understand that engineers have the tendency to overengineer. I myself think the same, concentrate on the important things and then add some things (after knowing what exactly). I do not know how Gunnar defines the requirements but there it is his project so for me the decisive point is does he break compatibility or not. If not it is at least not harmful and as I understand it you have the problems with the way he is adding new instructions but not saying that he breaks with existing software and compilers.

[OlafS3]

And btw, since Thomas is the guy who wrote PhoenixInit which the Phoenix core relies on for running AmigaOS at all, I suspect he may already have a board capable of running the Phoenix core. I know he has stated that he has a Natami developer board too. I would say it well worth to note that a person who has been responsible of updating core components of AmigaOS for a very long period of time, who has been involved in Natami development, who Gunnar himself says will take care of MMU issues in Apollo/Phoenix with his library pack... this same Thomas you claim have personal issues? Oh I don't know, I really just see a guy who keeps calling all critics "liars", but who refuse to disprove the lies, and instead just keeps pushing away those who could actually make his solution profitable for everyone.

What is your problem? On the holy crusade against Gunnar? You do not need to buy it and you do not need to use it.

[OlafS3]

Segment the platform?  You're joking right?  You do know that Commodore went bankrupt over 20 years ago so there's no longer a platform or any development for it.  And no market either.

Gunnar isn't defining a new platform.  He's taken an old one and improved upon it and you seem to have a problem with that.  We got that.  Now move along and stop bothering the rest of us who would like to see an improved 68K Amiga.

And for someone who has no technical problem with Gunnar's design, you sure do keep pointing out technical issues with Gunnar's work.  

If you don't like Gunnar's design, then don't use it!  Use a real classic Amiga, UAE, or one of the many other FPGA Amigas.  Or maybe you and Matt should join forces and create a design that beats even Gunnar's work.  According to you both, you guys know better than the rest of what we want or what we should have.

Thomas has a problem with Gunnar adding commands without exactly defining for what purpose they are needed. For me it is important that existing software works on it. If there are unused commands or not is not interesting to me.

[OlafS3]

I am not on any crusade against Gunnar, all I did was asking a simple question - will MacOS run under emulation on the Phoenix? That is really a question that can be answered with either "yes" or "no". A whole lot of indicators suggest "no", but Gunnar call those "lies". Promises are worthless in Amigaland, and Natami was a project flooded with promises. And fact is Gunnar has not promised _anything_, but people like you and certain others, keep posting on forums how this and that is promised. I really wish you could stop posting on behalf of people you do not represent. Gunnar has not promised _anything_, and in any case, promises are worthless - only running software has any true value here.

Curious - have you seen AROS running on Phoenix yet?

What are you up now? What is your problem?

[OlafS3]

Here's an idea.  Be a beta tester and see for yourself if MacOS will run on it or not!

no I have a better idea for him... stay away from the project and be happy with whatever he uses right now

[OlafS3]

My problem is obviously getting simple answers to simple questions - you are sn AROS/m68k user and distro maintainer - and you are eagerly involved in Apollo/Phoenix - there are plenty of people with Vampire600 and other boards that run Phoenix, you communicate with Gunnar and the Apollo team on their forum, people who should have no problem whatsoever to try out AROS on their hardware - have you ever seen AROS run on the Phoenix core? The answer is either "yes" or "no".

No not yet

And now?

What will you create by this?

[OlafS3]

@ferellsl

so you want to scare one of the main contributors like thor away from the project? are you going to take his place and develop support libraries? and if not, why dont you just hold your mouth or go using os4 or something like that, instead of alienating people here?

Certain people are doing their political agenda here

It is Gunnars time invested in the project not Kollas or any other

I see no reason to mistrust Gunnar there and the nice thing about FPGA is you can change it. So I do not understand what this discussion is about. Matt and Kolla can do a new FPGA core themselves if they think they are better. Simply as that.

[OlafS3]

Mike, do you see a need for and would you support a standard's committee? I speak of not just 68k enhancements but also custom chipset enhancements. We recently had a discussion on EAB about custom chipset implementations and enhancements.

http://eab.abime.net/showthread.php?t=77679

Without standards, we are going to end up with many different incompatible enhancements. One standard will gain more and better support from developers. Look at the support of CGFX and AHI which shows how important a standard can be, especially in a small market like the Amiga. Some people have said standards aren't important because the Amiga is on the brink of dying but we have to plan like it will live. New hardware with hardware standards may be what revives it. I tried to document a standard 68k CPU ISA starting back in 2012 but the Amiga was too dead then for most people to worry about. Gunnar would say it is all my fault for rocking the boat of his Apollo ISA standard but I believe his standard is too radical for other 68k FPGA processors to follow. We need more conservative standards which most FPGA hardware and UAE could adopt when there is developer support and software. Custom enhancements could be built on top of the standards. We can't have one person dictating the standards and half a standard is no standard at all. I don't think a standards committee is going to happen without representives from FPGA Arcade and Mist. I would like to hear from compiler developers if possible including Frank Wille and/or Volker Barthelmann (are there any other active Amiga compiler devs?). A-Eon may be interested. A standard's committee would benefit Gunnar as well. Any arguments could be voted on. Anyone should be able to submit ideas and listen in to discussions. I would probably be considered too biased to be chairman which is fine. We can elect someone. I'm not sure what platform would be best. Does anyone like the idea or have any suggestions for improvements?

The standard is the existing hardware (processor+chipset) and the rest is done by the OS (perhaps with special optimized libraries)

[OlafS3]

Allright, thank you for answering. I was just curious and I'm adding this to the pool of information about this project. I find it interesting that noone has bothered to test out AROS/m68k on Vampire600 yet.

*sigh*

then have nice dreams