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

[guest11527]

What I am not understand is how relevant this is in our case.

Lets look at some numbers
Phoenix today can reach over 300 Mips - this means Phoenix is like 20-30 times faster than todays ACA cards.
We see on the horizon the next gen FPGAs.
This means we can have a future roadmap where we know we can create cards with over 1000 Mips.

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.

The performance difference between Phoenix and old 68030 cards is so ridicolous that I think the wish to run future killer applications on both platforms is pointless.

Then why do we need new instructions in first place?

[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.

[guest11527]

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?

Yes, and yes. It creates potentially incompatible programs, confuses the user and pollutes the instruction space. The corresponding codes could probably be used for something more important. There are only little benefits, and there are only small drawbacks, but if you compare one to another, I come to the conclusion that it's not worth adding this stuff.

Only some powerhungry applications like a browser might use some special commands to speed up.

We've just learned that the overall speedup due to these instructions is probably close to zero. So why bother?

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?

It's a problem with the design philosophy I have here. You're not adding instructions to a core by holding your thumb in the air. Oh, the coldfire has these instructions, let's use them... An overall cost/benefit analysis has not been done, or done incompletely, and if you do, you come to the conclusion that there's nothing that would require(!) such instructions in first place. Now, if the design continues with this strategy (or lack thereof), the instruction space will be filled with lots of this stuff, and when we come to the important stuff (by experience from real-world problems), nothing will be left and we'll have a fragmented platform of various possible FPGA CPU-cores that are all slightly incompatible to each other because at some point some developer came up with another "neat new instruction".

That's not a good design principle, even less so for a platform that only lives from old legacy applications - and can only migrate away to something more powerful by having a single unique well-defined architecture.

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.

It's not about "coding" at all. For pure coding, this makes no difference. It is about "strategy" and "long term goals". At this time, any such extension is pretty premature and should be left alone, up to the point were concrete demands require an extension. Then, a careful choice of instructions in an open discussion should be started, finally leading in testing and implementation. But only then.

[psxphill]

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 think you've summed up the problem quite well except I'm not bothered about gunnar wasting his own resources.

The hurt comes from another fpga project that is taken over by someone pushing their own agenda.

Once someone makes an fpga board that can be configured to run 100% compatible to original Motorola chips then people can buy them with confidence that it won't turn into a mess further down the road. I'm not against optimisations, as long as they don't impact compatibility (which means you can't add registers or instructions to the cpu core).

[Gulliver]

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.

[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.

[paul1981]

If code is compiled for 68000 with an existing/old compiler such as SASCv6, isn't 68K/AmigaOS compatibility guaranteed throughout the Amiga range when fitted with the new forthcoming Vampire cards?

[guest11527]

If code is compiled for 68000 with an existing/old compiler such as SASCv6, isn't 68K/AmigaOS compatibility guaranteed throughout the Amiga range when fitted with the new forthcoming Vampire cards?

Yes. But given how much code was actually compiled for the 68020 on the Amiga (off your head, how much do you know?) how much sense makes another extension, now that the community basis is a lot smaller than back then?

[wawrzon]

for those who dont understand: running mac emulation on phoenix/apollo core is merely just a test case. i dont think there is "whining". perhaps just a bit too much emotionality here and there.

edit:
perhaps the best thing is to get the test boards underway and let the project gain its own dynamic, which i trust due to reconfigurability of fpga and customer/tester feedback might take a good direction in the end. we have a very competent and well opinioned people on this project. lets face it, investments in a range of around 150.- are worth the risk. i would sure think twice if it was 500.-

[kolla]

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?

[kolla]

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?

[ChaosLord]

@Thomas Richter

You seem to put a lot of energy into opposing the addition of new instructions added in to Jay Miner Compatible Computers.

I would dearly love to read some of your criticisms of Intel adding in new instructions to Bill Gates Compatible Computers.  Where may I read these scathing criticisms?

Intel gets to add new instructions all the time.  Endlessly.  This must frustrate you terribly.  It would be most enjoyable to me to read your crushing rebukes of Intel Corporate Policy.

If you could provide a link to some of your old writings or just write up some of your complaints against Intel here in the forum then I am certain they would be very educational.

Thanks!

[guest11527]

I would dearly love to read some of your criticisms of Intel adding in new instructions to Bill Gates Compatible Computers.  Where may I read these scathing criticisms?

There is none, and I don't have a critique on intel. What you and many other people do not understand is that the whole situation with intel is a different one. There is a huge active user community for intel, lots of commercial vendors, lots of software companies developing products, and a customer base that is willing to pay for it. Thus, if you add new instructions, there will be companies picking them up, and users that will pay for them. There will be software that uses them, and there is even the chance that software will slowly migrate away from the old legacy, as they did from BIOS or real-mode.

The situation *here* is a completely different one. There are no new companies developing software for the Amiga, there are no commercial vendors, only legacy applications, and not enough manpower to develop new products. There are no customers paying for them. The whole "amiga market" - if there is such a thing - lives from the legacy CBM left behind. There is no chance that Amiga will migrate away to something more modern. There is already a lot more modern than Amiga, so if you make the cut, make it for real.

Thus, if you are aiming for something new, there are plenty of options for you. Intel and PC is one of them. Hyperion offers other options. AROS is an option, or Linux is an option. But amiga is an old platform, only defined by its legacy.

[ferrellsl]

@MattHey
@Thomas Richter

Why do you two keep bringing up these pointless arguments about additional instructions and Mac compatibility?  It's obvious that you two have something personal against Gunnar since you continue to bombard this thread with the same non-issues.

This is an FPGA project.  If you don't like Gunnar's core, then flash it with one of the Minimig cores and go on your merry way and leave the rest of us alone.  Or better yet, do something constructive like contacting the author of WHDLoad and ask him to update WHDLoad with Gunnar's new core in mind.  That would solve all of these non-problems you two keep bombarding us with.

[kolla]

You mean TG68 core from Tobi, the Minimig core is the chipset, not CPU. The Apollo team is nowhere near anything else but talks when it comes to chipset implimentation, talks about SuperAGA/SAGA when they have not been able to show anything working at all yet.

[kolla]

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.