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

[Lurch]

I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.

[OlafS3]

I don't mind the debates, some of it is interesting reading. What I don't like is the negativity.

The debates on apollo forum were in the same tone as here (partly worse). Matt can like it or not but decisions and work is not done by him but by Gunnar and some others. At the end the result counts and we will see it when we will have and use the new cards. That debates if one register more or less is better or worse or if without one command the world goes under are nerving. If Matt would want to help he would buy a card and help testing and help to improve compatibility instead continuing the debate from apollo forum on a public forum where people only get wrong impressions.

Regarding ISA extensions I am of the same opinion that supporting existing ISA is more important than extending it because we have only few developers (like Novacoder) left who would really use this new commands. Most others are using compilers. We have a huge 68k codebase with lots of compilers, libraries and applications and games but many of these are closed or written in asm. Who will adapt the compilers? And even when they are adapted many programs are not available in source. So most energy should be invested in getting the most for the existing codebase.

The rest of the debate between Matt and Gunnar was that Matt preferred something different because what Gunnar does would be not best for ASIC and Gunnar denied that. I cannot judge who is right or wrong there and I do not care. Sorry Matt I do not believe that there will be any ASIC design in foreseeable future (high costs) and if someone would really invest in such a project the design certainly could be adapted (assuming that Matt is right at all, Gunnar is working at IBM so he should have some clue too). I want the best for existing FPGAs. Besides I think FPGA is more interesting and has more geek factor than ASIC right now.

[alphadec]

I hope I gets the chance to buy one card and I love to test it.

[psxphill]

This means all cards for all AMIGA systems e.g. A600/A500/A1200/... will support the same instruction set and the same features and have the same capabilities.

 So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
 
 Hopefully you will open source it so we can remove them.

[OlafS3]

So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.
 
 Hopefully you will open source it so we can remove them.

Huh?

Was that a joke?

[biggun]

So you've managed to get everyone to agree to buy into your ISA extensions? How depressing. It is truly a sad day.

The ISA extension are 100% compatible with old code.
There are no negative side effects.

All old code will work.
And new code has the option to use them for your benefit.

But no one is forced to upgrade now to a 200 Mips CPU.

If you do not want more Mips, more perfomrance, higher memory bandwidth or faster instructions - simple just keep your old CPU.

[guest11527]

The ISA extension are 100% compatible with old code.
There are no negative side effects.

There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores.  I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.

[OlafS3]

There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores.  I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.

what do you mean with old and new core?

old core is existing 68k processors? If the new ISA supports old ISA what is the problem adding new except almost no software will use it?

[biggun]

As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it.

Maybe the ISA should really not be discussed here.
Most people do not understand the topic and get only confused.

Regarding forward compatible of old system.
The new card offer performance levels of 68030 systems with 500-1000 MHz.
How sensible is running future games or demanding webbrowser
which will depend on this speed on 16 MHz 68020?

Regarding whether the added value is low or high.
Trust me the added value is HIGH the changes give over 300% speed up  in FPU area for example.

I can show you example code which demonstrates this.
If you want more details to understand this - lets move over to Apollo forum.
Here is not the technical audience.


Cheers

[ElPolloDiabl]

If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.

What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?

[guest11527]

Trust me the added value is HIGH the changes give over 300% speed up  in FPU area for example.

The added value of the modified ISA is certainly not HIGH. What can you do now you could not do before? Instead, you rather enable people to create incompatible programs that could have been created on the existing platform with only minor modifications and with only a very minor loss of performance.

I know, there is the cycle counter party whose members would sell their grandma to reduce the number of clock cycles in a totally uninteresting part of a program, and maybe you want to address the demand from those folks. However, beware! The outcome of such activitly is usually less useful than one may hope for, leave alone the stability, and the increased performance is usually not what you have hoped for.

Increasing clock speed, caches and so on - these are all forwards-compatible extensions that are well regarded and hoped for. Adding new instructions is not.

[wawrzon]

There are two forms of compatibility: Backwards compatibility (new core can execute old code) and forwards compatibility (old core can execute old code - to some degree). Backwards compatibility is given, forwards compatibility is not given. It would be given if the instruction set would be identical, though execution would only be slower or less elegant on older cores.  I neither agree that there are "no negative side effects". From a purely engineering point of view, this is probably correct. But engineering is not everything. As I say, it segments the platform, and the added value is low. If the added value would be higher, I the ratio would be better and I would be for it. Other than that, I would really prefer if you could remove this stuff. I.e. d(PC) is constant EA (non-modifyable) no 8th address register hidden somewhere, no additional data registers. There is really not enough room in the Amiga to add such low-level stuff in first place.

i agree on that, there is no detailed technical expertise to understand this problem.

however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.

@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.

[biggun]

If you are going FPGA which is better at parallel processing instead of raw MHz just keep going with it. It will probably end up better or faster than a Coldfire system.

What can be done on the software side to fix this? Could you add libraries that make it Coldfire compatible?

To whom do you talk?
Phoenix is  faster than Coldfire already.
What do you want to fix in software?

[biggun]

The added value of the modified ISA is certainly not HIGH.

What is your definition of high?
Is trippling the FPU speed with new ISA high?

[OlafS3]

i agree on that, there is no detailed technical expertise to understand this problem.

however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.

@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.

Sometimes I have problems to understand the problems. All old code should run on it (as fast as possible) and of course when new 68k software is developed (for 68000-68060). Most people will use compilers and not directly write asm so compiler generated code should also work. Then there could compilers be extended to support new commands but that would be only a new compile if you use a high-language and as long as you are aware that this code needs apollo I do not see a real problem. If someone writes asm he certainly knows anyway what he does. There should be documentation then what is supported by old ISA and what is only available on new ISA. And the programmer then has to decide. But in general I do not see a real problem. I think technicians sometimes are lost in the wood nobody else even see and are only irritating others by becoming ideologic/religious about it (what it sometimes seem to me).

[OlafS3]

i agree on that, there is no detailed technical expertise to understand this problem.

however gunnars argument is to certain extent valid, that if the new code in question couldnt run on old cpu at practicable speeds anyway, then no forward compatibility is necessary. likely there is though no dependable category to prove this, i fear.

@gunnar
i think the best step now would be to make documentation publicly available and let it be discussed no matter what. there will always be differences and unpopular or arbitrary choices may be necessary. but there also may be ideas worth consideration and openness is rather likely to convince the opposition than "dictatorship" is likely to silence it.

Might be that many programs are not benefitting from it because they were compiled with compilers not supporting these new instructions or even written in asm not using this commands but I do not understand why it is a real problem as long as 68000-68060 code works on it. Who wants to use the new commands has either use new compilers (with a new apollo target) or write it himself in asm. As long as people are aware that apollo specific code not necessarily runs on 68000 I do not really see the problem. Anyway hopefully apollo (+new chipset) becomes the new standard and nobody will then care about a plain A500 when developing a new software. I think there of demanding applications and games, who will try to run them on such hardware anyway?