Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

Performance and Software for 2018page  1 2 3 4 

Asaf Ayoub

Posts 26
28 Nov 2017 22:07



The point of C code is - that its compatible to all models

Its not if its written in different class of compiler than available or if the C source includes 68080 specific assembler code.

If some C code includes specific 68080 instructions to speed up line draw, then it should still be able to back port 68080 asm line draw into 68000 asm line draw equivalent commands 'to draw a line' but not as optimised.

This would be even more problematic when trying to convert 68080 assembler to 68000 equivalent code.

Just like PortAsm software 68k to coldfire translation EXTERNAL LINK 
But backwards 68080 -> 68000 source code translation.




Asaf Ayoub

Posts 26
28 Nov 2017 22:12



Steve, fair enough but you still missed the point that a developer accustomed to coding in C/C++11 would be severely limited and frustrated writing software to accommodate a lack of functions they expect and hinder their own code fluidity & creativity.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 22:18


Asaf Ayoub wrote:

But backwards 68080 -> 68000 source code translation.

 
I think here is a misunderstanding.
You try to fix something - which is not broken.
 
 


Steve Ferrell

Posts 424
28 Nov 2017 22:18


Asaf Ayoub wrote:

 
    Steve, fair enough but you still missed the point that a developer accustomed to coding in C/C++11 would be severely limited and frustrated writing software to accommodate a lack of functions they expect and hinder their own code fluidity & creativity.
   
   
 

 
No I haven't missed the point.  The functions you're referring to exist in C99 all the way thru C++17 so why would you be hindered?  The limiting factors are the two operating systems!  These functions don't exist in OS3 or OS4!  The only way for that to change is for Hyperion to update OS4.....and it will never happen for OS3 because of its legal status!
 


Mo Retro

Posts 241
28 Nov 2017 22:33


Gunnar von Boehn wrote:

Asaf Ayoub wrote:

  But backwards 68080 -> 68000 source code translation.
 

 
  I think here is a misunderstanding.
  You try to fix something - which is not broken.
 
 

I think what Asaf Ayoub means is that the new coded programs should be compatible with the 68000.
That means no use of AMMX and other 080 instructions.
Personally I think that's undesirable by all Vampire owners. We want that new software use every feature and enhancement that the 080 offers and not generically programmed to run down to a 68000. That's just like having a 12 cylinder engine car and only use 4 cylinders to allow other 4 cylinder engine cars to match their performance.



Asaf Ayoub

Posts 26
28 Nov 2017 22:45



Mo Retro, almost but if you AMMX routines draw a line, then that could be coded in raw 68000 code, just not as fast. Maybe even software compatibility library.

A lack of AMMX functionality may not necessarily mean a lack of a specific feature on previous gens.

But in 2020 when their is Vampire/Apollo 68090 AMMX v9 only instructions & binary, one will break again and not work with current gen 68080 AMMX instructions.

Is this the roadmap everyone want to go ? just clarifying roadmap and code compatibility requirements for source code.



Steve Ferrell

Posts 424
28 Nov 2017 22:57


Asaf Ayoub wrote:

  Mo Retro, almost but if you AMMX routines draw a line, then that could be coded in raw 68000 code, just not as fast. Maybe even software compatibility library.
 
  A lack of AMMX functionality may not necessarily mean a lack of a specific feature on previous gens.
 
  But in 2020 when their is Vampire/Apollo 68090 AMMX v9 only instructions & binary, one will break again and not work with current gen 68080 AMMX instructions.
 
  Is this the roadmap everyone want to go ? just clarifying roadmap and code compatibility requirements for source code.
 

Why would anyone who codes for the Vampire develop software targeting the least common denominator which is a bog standard, unexpanded A500?  That's rhetorical....because the correct answer is: "for the same reason Vulkan programmers don't target users who own systems with 8086 processors and CGA graphics".



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 22:57


Asaf Ayoub wrote:

  But in 2020 when their is Vampire/Apollo 68090 AMMX v9 only instructions & binary,
 

 
  Relax!
  I think you "invent" problems where there are none.
 
  The AMIGA used so far 68000,68010,68020,68030,68040,68060, and 68080 CPUs.
 
  68020 code will crash on 68000. This was always the case.
  And this situation was always like this since 30 years.
  68010 instruction will crash on 68000.
  68040 instruction will crash on 68030 / 68020 /68000 even on 68060
 
  The last 30 year everybody in the world was living with this situation. There is absolutely no reason to panic now.
 
 
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 23:02


Asaf Ayoub wrote:

    But in 2020 when their is Vampire/Apollo 68090 AMMX v9 only instructions & binary, one will break again and not work with current gen 68080 AMMX instructions.
   

     
VAMPIRE-2 with 68080 using AMMX is about 400 times faster than 68000.
This means program needing VAMPIRE power now, can never run on stock AMIGAs
 
The same will be true in 2024 with APOLLO-ASIC running at @ 6 GHz.
This APOLLO-CPU will then be 50 times faster than todays VAMPIRE-2.
Program needed the power of a 6 GHz APOLLO will not run sensible on a 80MHz Vampire anymore.
   
What you ask for, is like adding 64bit ASM emulation to x86 code
so that you can run Windows10-server edition in 64bit mode with ORACLE-DB on your 80268 with 640KB memory.
This makes no sense at all.
     
Today programs using AMMX are program needed real horse power.
Like a Video or DVD player - expecting to run them on stock A500 is a pipe dream.
The stock A500 can not display the needed amount of colors, does not have the needed amount of memory, and is 400 times to slow for this job.


Thierry Atheist

Posts 644
29 Nov 2017 07:42


Gunnar von Boehn wrote:
Asaf Ayoub wrote:
But in 2020 when their is Vampire/Apollo 68090 AMMX v9 only instructions & binary, one will break again and not work with current gen 68080 AMMX instructions.

What you ask for, is like adding 64bit ASM emulation to x86 code so that you can run Windows10-server edition in 64bit mode with ORACLE-DB on your 80268 with 640KB memory.

HA HA HA HA HA!!! LOL!!!!!!


Sean Sk

Posts 488
29 Nov 2017 14:29


Asaf Ayoub wrote:

But backwards 68080 -> 68000 source code translation.

In other news, DICE plan to develop Star Wars: Battlefront 3 with 486DX backwards compatibility.



Asaf Ayoub

Posts 26
29 Nov 2017 19:50


Yes, make fun all you want.
 
Sean Sk, LOL not to that extent.

  If it makes you feel good inside ;) , I was just concerned about maintaining some sort of standardised 68k assembly language.

If you want that to be 68080 so be it.
 
Have fun
  My bad. :)


Mr Niding

Posts 459
29 Nov 2017 20:09


Asaf Ayoub wrote:

 
Yes, make fun all you want.
   
If it makes you feel good inside, I was just concerned about maintaining some sort of standardised 68k assembly language.
   
This forum is obviously not a welcoming place for that.
   
My bad.
 

 
Never let random faceless forum gnome chase you away from asking questions. The only person in this thread which words have any impact is Gunnars.
Dont let others rile you up, cause at the end of the day, their words are worthless with regards to design decisions.
They can, like you, only give inputs, but only people that put code on the table have real impact. Jari and SoftFPU being prime example.


Philippe Flype
(Apollo Team Member)
Posts 299
29 Nov 2017 21:33


At ASM source code level, Standardized 68k code is already existing, it is coding for the Machine MC68000, it then runs on all 680x0. standard code always run faster on newer 680x0 either because of higher clock or better design (cache, pipelines, ...).

At C source code level, code is always able to be compatible on all 680x0 (assuming not doing super tricky stuff). It is up to the coder to choose compile for mc68000 compatibility and then it runs everywhere (assuming we talk of system friendly compatible code).

Now when talking about being able benefits of all 680x0 revisions / optimizations with only one binary is quite nighmare and will end to bigger (huge) executable files which not really the amiga philosophy. Generally, this have to be solved with external libraries which are specific to a system/machine but transparent for the program that use them. Example: even in assembly one should use os mathlib->div() rather than div instruction so that it ensure it runs best on all system. Same goes for ammx, just use the external sdlammx library.


Steve Ferrell

Posts 424
29 Nov 2017 22:15


Asaf Ayoub wrote:

       
        I was just concerned about maintaining some sort of standardised 68k assembly language.
       
        If you want that to be 68080 so be it.
         
        Have fun
          My bad. :)
       

       
You clearly have no idea what you're talking about.  The 68K assembly language has been standardized for years.  The 68080 uses the very same instruction set of all the previous 68K CPUs that preceded it, but it has the added advantage of the AMMX extensions for those who want to make good use of them.  These AMMX instructions have been published and work in the same manner as the MMX extensions on Intel CPUs.
       
If the Vampire developer targets the 68060/80 CPU, then of course the code generated won't run on a vanilla 68K processor or even an 030 or 040. If the Vampire developer wants to target the 68030, then he can do that as well, but of course his code will only run on an 030 or greater processor.  The same can be said for nearly every other architecture out there as well.  So why do you dream up problems that don't even exist?
       
       
       
       


Renee Cousins
(Apollo Team Member)
Posts 142
30 Nov 2017 02:34


Gunnar von Boehn wrote:
What you ask for, is like adding 64bit ASM emulation to x86 code so that you can run Windows10-server edition in 64bit mode with ORACLE-DB on your 80268 with 640KB memory. This makes no sense at all.

There is a real world example of this. Dmitry Grinberg wrote an ARM emulator complete with MMU for the 8-bit AVR and successfully booted Linux using a hard-wired bit of RAM and Flash. It's not fast -- it took about two hours to boot to a bash prompt -- but it is a real example of this. The Cortex-M0 version is considerably faster and could have practical uses.

In a real-world sense, this can be used to give a processor functionality that it would otherwise lack. FEMU comes to mind. You could also emulate a 68K on a 68K to add MMU and use some pseudo-JIT to minimize the overhead. The infamous ColdFire library that allows full CPU32 code to run on it is also a good example and one that was widely used and could have been used as a stepping stone for an AmigaOS port (sadly, no one seemed interested in that option and in hind-sight, ColdFire is dead now, so that would have been a short road).

Similar software exists on x86. There were x87 emulators to give you a fake FPU for poorly written software (getting it and your game to fit under 640KB was painful). However, upward emulation hasn't been terribly important since backwards compatibility is so strong on the PC. A 486 will run Windows 2000 and if you have a board with any Pentium or Pentium Overdrive chip you can even install Windows 7.

Of course no one's going to run a database on something like that -- that's getting a little facetious.


Renee Cousins
(Apollo Team Member)
Posts 142
30 Nov 2017 02:38


Asaf Ayoub wrote:
Mo Retro, almost but if you AMMX routines draw a line, then that could be coded in raw 68000 code, just not as fast. Maybe even software compatibility library.

In most cases, developers have continued to maintain non-AMMX versions of their programs. There are also AMMX optimized libraries and datatypes that you do NOT have to use if you do not want to. Netsurf should run fine on a stock 68060, but with some AMMX JPEG datatypes and the extra processing power of a Vampire, makes for a nicer browsing experience. So far, there's almost nothing that REQUIRES a Vampire. That's going to change.

And if you want to be part of it, buy a Vampire. If you're happy with your Amiga 500 with it's 7.16MHz 68000, then keep it. But don't expect anything written with a 400MIPS processor in mind to run AT ALL on it -- compatibility or none.


Steve Ferrell

Posts 424
30 Nov 2017 02:45


Renee Cousins wrote:

Gunnar von Boehn wrote:
What you ask for, is like adding 64bit ASM emulation to x86 code so that you can run Windows10-server edition in 64bit mode with ORACLE-DB on your 80268 with 640KB memory. This makes no sense at all.

 
  There is a real world example of this. Dmitry Grinberg wrote an ARM emulator complete with MMU for the 8-bit AVR and successfully booted Linux using a hard-wired bit of RAM and Flash. It's not fast -- it took about two hours to boot to a bash prompt -- but it is a real example of this.
 

And just as Gunnar stated, this makes no sense at all and has no "practical" use.  Why would anyone want to run a game or other application written for a Vampire on an unexpanded 68K Amiga when the frame rate would be measured in minutes or hours per frame, not frames per second?  I can also use my abacus to perform calculus but why on earth would I or anyone else want to do that?  I suppose if I was just wanting to waste my time and perform a given task in as many steps as possible.....a masochist's dream!  But news flash!  People use computers to automate and speed through tasks, not slow them down!




Renee Cousins
(Apollo Team Member)
Posts 142
30 Nov 2017 02:54


Steve Ferrell wrote:
And just as Gunnar stated, this makes no sense at all and has no "practical" use.  Why would anyone want to run a game or other application written for a Vampire on an unexpanded 68K Amiga when the frame rate would be measured in minutes or hours per frame, not frames per second?  I can also use my abacus to perform calculus but why on earth would I or anyone else want to do that?  I suppose if I was just wanting to waste my time and perform a given task in as many steps as possible.....a masochist's dream!  But news flash!  People use computers to automate and speed through tasks, not slow them down!

Sometimes people need to run CODE-X and only have PROCESSOR-Y. It's surprisingly common. As I said, FEMU does this. The non-Vampire version of FEMU is considerably slower than any 68K FPU, but it's still there and it's pretty handy for those programs that need an FPU. Does it make my system crawl to a halt -- not really, since MOST of the code is still normally 68K stuff.

Also, maybe calm down, take a chill pill.


Steve Ferrell

Posts 424
30 Nov 2017 03:05


Renee Cousins wrote:

           
        Sometimes people need to run CODE-X and only have PROCESSOR-Y. It's surprisingly common. As I said, FEMU does this. The non-Vampire version of FEMU is considerably slower than any 68K FPU, but it's still there and it's pretty handy for those programs that need an FPU. Does it make my system crawl to a halt -- not really, since MOST of the code is still normally 68K stuff.
       
        Also, maybe calm down, take a chill pill.
     

     
You're getting to be as absurd and off the rails as Asaf.  You're stating that emulating an FPU is the same as what Asaf is suggesting,  and it isn't....not even close.  Emulating a small set of floating point instructions on a CPU not equipped with an FPU is NOT the same as taking a CPU such as an 8086 and having it emulate the full instruction set of an Intel Core i-7 CPU "AND" its integrated FPU and memory manager.  In the preceding sentence, replace the 8086 and i-7 with the architectures of your choice for full effect.

And no, this ISN'T surprisingly common.  If it were, people would still be using 8086 processors and trying to decode x.265 video streams, but they aren't and for good reason.  There would also be translation layers allowing people to run CUDA apps on 80286 PC's with EGA graphics boards too....and there are none. Or wait, what about a commercial product that lets you run Windows 10 on an 8088 CPU?  Again, there isn't such a product nor a need for it. So common for whom? Researchers who have a lot of time on their hands and a budget provided by the state?
     
And I'm quite chilled at the moment, thank you, even without taking a pill, but you and Asaf need to get a clue.
     

posts 73page  1 2 3 4