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 13:36



Hi

I would like to suggest the following software to test Apollo systems :

In 100% 68000 mode

Uclinux running native on Apollo systems

Unfortunately at present Uclinux only supports Coldfire.

We need be able to cross compile to Linux 68k, And Amiga 68k

This will open up a good path to convert linux software to Amiga systems.

Later one could use qemu emulating Coldfire to create a Cross Compile Toolchain.

A working C/C++11 cross compile toolchain that keeps Files and Folders in same place for all developer tools, is a must.

Download from source repository like Linux has, is necessary.

Improvements, consistency, speed tests to optimize builds and compile times would be challenging.

Without a way to access uptodate tools will only hinder developers, slowing them down - developers just want to create magical software.




Thierry Atheist

Posts 644
28 Nov 2017 14:21


Isn't NOT using 68060 and fused assembler instructions (and the 64 bit ones)... going backwards?


Samuel Crow

Posts 424
28 Nov 2017 15:07


Asaf Ayoub wrote:

In 100% 68000 mode

What else is there?  UAE?
Asaf Ayoub wrote:

  Uclinux running native on Apollo systems
 
  Unfortunately at present Uclinux only supports Coldfire.

Not worth the effort.  Compile on a RasPi.
Asaf Ayoub wrote:

  We need be able to cross compile to Linux 68k, And Amiga 68k
 
  This will open up a good path to convert linux software to Amiga systems.

Uh, no we don't and no it wouldn't.  Linux sources aren't that compatible with Amigas.
Asaf Ayoub wrote:

  Later one could use qemu emulating Coldfire to create a Cross Compile Toolchain.

It still wouldn't be compatible with the 68080.
Asaf Ayoub wrote:

  A working C/C++11 cross compile toolchain that keeps Files and Folders in same place for all developer tools, is a must.

This, by itself, makes sense.  Is the rest just some attempt at a lengthy "shortcut" that takes longer than porting Clang or GCC to AROS or AmigaOS?
Asaf Ayoub wrote:

Download from source repository like Linux has, is necessary.
 
  Improvements, consistency, speed tests to optimize builds and compile times would be challenging.
 
  Without a way to access uptodate tools will only hinder developers, slowing them down - developers just want to create magical software.

A packager might be handy but only if dependencies like shared libraries become a problem.  Let's try to keep things simple though.  Even AmigaOS 4 doesn't have a packager yet and it has lots of Linux derived stuff going on.  How is porting Linux going to help?

I do agree on the singular point of needing an up-to-date compiler setup.


Steve Ferrell

Posts 424
28 Nov 2017 16:06


Asaf Ayoub wrote:

 
    Hi
   
    I would like to suggest the following software to test Apollo systems :
   
    In 100% 68000 mode
   
    Uclinux running native on Apollo systems
   
    Unfortunately at present Uclinux only supports Coldfire.
   
    We need be able to cross compile to Linux 68k, And Amiga 68k
   
    This will open up a good path to convert linux software to Amiga systems.
   
    Later one could use qemu emulating Coldfire to create a Cross Compile Toolchain.
   
    A working C/C++11 cross compile toolchain that keeps Files and Folders in same place for all developer tools, is a must.
   
    Download from source repository like Linux has, is necessary.
   
    Improvements, consistency, speed tests to optimize builds and compile times would be challenging.
   
    Without a way to access uptodate tools will only hinder developers, slowing them down - developers just want to create magical software.
   
   
 

 
Then I suggest you get busy and implement your suggestions.  You make up less than 1% of the people here who even care about ucLinux let alone anyone who actually wants to run it.
 
And no, this won't open a path to porting Linux software to Amiga systems.  The API and OS are completely different unless you're talking about some very basic command-line and text-only apps....most of those have already been ported.  Others will never be ported because the Amiga's API doesn't support a host of POSIX functions such as fork(), glob(), globfree(), etc...
 


Wawa T

Posts 695
28 Nov 2017 18:12


Posting Linux stuff to Amiga is usually achieved via a compatibility Laser such as ixemul Library. Aros has posix compatibility Laser built in. However neither offers full Set of Linux Features. Fork is impossible to implement. Posting some Linux Distributionen to 68k has nothing to do with it.


Asaf Ayoub

Posts 26
28 Nov 2017 20:41


@Samuel Crow
 
 
What else is there?  UAE?
 

  You answered this already- to 68080 assuming your never realising an 68090 in future. Thanks for the clarity.
 
 
It still wouldn't be compatible with the 68080.

 
  I did not know that Apollo team is not interested in keeping & maintaining 68000 compatibility across all spectrum of 68k devices. Which Apollo 68080+ grow from. Is this your personal view ? Or team view ? Very interesting viewpoint. Noted.
 
  If as you say, are focusing on Apollo 68080 only and its future processors this then optimised for 68080 (in C or asm) would remain incompatibly with base 68000 machines. Basically one would have an incompatible system - 'your out of luck fella.'
 
   
This, by itself, makes sense.  Is the rest just some attempt at a lengthy "shortcut" that takes longer than porting Clang or GCC to AROS or AmigaOS?

 
  Truth is I do want up to date GCC compile tools for 68k baseline like C/C++17, Go.
 
  I have not heard anyone on the Apollo team mention GCC/C++ tools or any standard developer tools in general. Any modern developer wanting to develop on 68k systems expects at least C/C++11 standard and other libraries or they will give up and move on.
 
  This has brought to light alot, thank you so much for responding with diligence.
 
  I will always pursue a common 68000 core baseline for all compatible systems with a common source core for all. You may want different - Its all good though :).
 
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 20:50


Asaf Ayoub wrote:

I did not know that Apollo team is not interested in keeping & maintaining 68000 compatibility across all spectrum of 68k devices.

I do not understand what you try to word here.
Can you please rephrase this?


Asaf Ayoub

Posts 26
28 Nov 2017 20:51



Yes, Wawa Linux does have posix, we just need to focus on core tools and try update them and remove the incompatibility.

If we dont we are going to have scripts that require certain levels of software (command line) not working correctly, then once broken lost and forgotten about.

I know some developers may say leave out the old stuff - no ones going to use it. Thats their choice. I believe every tool is important for next generation and TRY best keep the source code compatible & updated or they would say 'what one earth have we been doing ?'


Michal Warzecha

Posts 209
28 Nov 2017 20:56


Hardware is not done yet but You want have all languages/compillers ready to use. Relax, let them complete Vampire first.
And Linux is not target for Vampire. This system You can run probably even on washing machine, it's waste of time porting any Linux distibution to Amiga. We need focus to AOS or AROS development.


Asaf Ayoub

Posts 26
28 Nov 2017 20:59



@Gunnar

Sure, from Samuel Crows post it come across the FOCUS of Apollo is ONLY 68080 cpu compatibility.

Their is alot of chat about optimisation of 68080 cpu (mostly in assembler) which is good, but also inherently creates a divergence away from pure 68000 processor.

I hear little chat about 68000 compatible systems, source code compatibility.

For example in 20 years time will we have full source code repository of 68000 compatible code, will Apollo core still be compatible ?

We will may well have C code for 68080 with asm inside - that will not work on vanilla 68k system.

When someone create cross compiler which is most compatible target for all systems ? Any ?


Steve Ferrell

Posts 424
28 Nov 2017 21:00


wawa t wrote:

Posting Linux stuff to Amiga is usually achieved via a compatibility Laser such as ixemul Library. Aros has posix compatibility Laser built in. However neither offers full Set of Linux Features. Fork is impossible to implement. Posting some Linux Distributionen to 68k has nothing to do with it.

Yes, and the 68K ixemul library is very outdated.  I think it was last updated in 2010 and it still lacks many POSIX functions, not just the ones I mentioned earlier.  I think signals are also missing.  Filling the 68K software gaps won't happen by porting ucLinux to the Vampire.  That is a total waste of time.  The gaps will be filled by porting cross-platform developer tool kits such as QT or FLTK to OS3.  FLTK and QT have been ported to OS4 and maybe one day we will see them ported to OS3.

But OS3 has over 20 years of catching up to do before we can expect to see modern apps being ported over using modern dev environments using CMAKE/qmake.  And legal issues aside, for that to happen OS3 needs a complete overhaul and the changes would be so great that most likely it wouldn't even be considered an AmigaOS afterward.

That's why I think the best way forward is with AROS.  It would be great if AROS x86_64 could be back ported for 68K.  This would go a long way towards solving the portability issues with fork(), SMP, threads, and a host of other issues related to porting Linux apps to an Amiga-like system.


Asaf Ayoub

Posts 26
28 Nov 2017 21:06


@Michal

I was only suggesting a route one could take for cross compilation to 68k so we can get C/C++11 compiler and tools up to date.

If it was easy we would have it for 68k wouldnt we ? So we do in fact have a problem getting up to date compiler /IDE etc.

  We need focus to AOS or AROS development.

I agree, but reading a lack of projects documenting porting software to amiga using modern tools and compilers - I mistakenly came to the concision it must be an impossible dream.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 21:06


Asaf Ayoub wrote:

I hear little chat about 68000 compatible systems, source code compatibility.

Not sure I don't understand your question.

68080 supports 100% all instruction of 68000.
Was this your question?


Steve Ferrell

Posts 424
28 Nov 2017 21:11


Asaf Ayoub wrote:

  @Gunnar
 
  Sure, from Samuel Crows post it come across the FOCUS of Apollo is ONLY 68080 cpu compatibility.
 
  Their is alot of chat about optimisation of 68080 cpu (mostly in assembler) which is good, but also inherently creates a divergence away from pure 68000 processor.
 
  I hear little chat about 68000 compatible systems, source code compatibility.
 
  For example in 20 years time will we have full source code repository of 68000 compatible code, will Apollo core still be compatible ?
 
  We will may well have C code for 68080 with asm inside - that will not work on vanilla 68k system.
 
  When someone create cross compiler which is most compatible target for all systems ? Any ?

Jens is sponsoring VBCC development and I'm pretty certain that it will support the Vampire and the AMMX instruction set:  EXTERNAL LINK 




Asaf Ayoub

Posts 26
28 Nov 2017 21:15



Steve, I suggested ucLinux only because it is light, could be run in 68k Coldfire emulator to make any ports that much easier.

Im talking mostly command line tools to try keep in sync with linux distros.

The situation we have in OS4 land is source code being too old compilers break and never ending dependency issues.

Every c/c++ code example/source ocde program in 2017 that uses C++11 or c++17 will never work on Amiga system ever until the compiler is updated.



Asaf Ayoub

Posts 26
28 Nov 2017 21:21



Partly, i mean also backward source code compatibility to 68000. Source repository. Like linux. download then compile for All amiga
  like systems, even Aros - all same code base - all same tools, same version numbers everything.

No more nightmare coding.

I also mean Cross compilers currently support C/C++ compile to 68k coldfire only - how can we get working for all 68k systems ?




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 21:26


Asaf Ayoub wrote:
 
Partly, i mean also backward source code compatibility to 68000.

 
Maybe we have a language/misunderstanding problem here.
And this is causing all the confusion?
 
_68080_ does support:
100% of all 68000 instructions
100% of all 68030 instructions
100% of all 68040 instructions
100% of all 68060 instructions
So 68080 is fully compatible.
 
Of course program compiled for 68020,
did crash on 68000,68010, and can also crash on 68060.

Of course program compiled for 68030,
will crash on 68000,68010, and can also crash on 68060.
But they will run correctly on 68040, and 68080.

Of course 68000 does NOT support all instructions of 68030 or 68040.
Even 68060 does NOT support all instructions of 68040.
 
So an EXE is compiled for 68040, then it might not work on
68000, not on 68010, and not on 68060.
Maybe it will also not run on 68020 and 68030.
But it will always work on 68040 and 68080.
 
 
68080 has of all CPUs in the 68K family to widest instruction set support - and is the most compatible.

Coldfire is generally a subset of 68000.
This means programs compiled for the right COLDFIRE model will run fine on 68k.



Asaf Ayoub

Posts 26
28 Nov 2017 21:38


exactly my point any optimisations will not work on any cpu lower, especially if they are asm optimisations.
 
  Should we have C code or assembler code compatibility back to 68000 ?
 
  Should there be a way to back roll 68080 to 68060 to 68040 to 68020 to 68000 using software to keep 68k base source code ?
 
  So any new 68080+ code will always be able to convert to 68000 asm code. For a git hub/repo for 68000 source code.
 
  I want to eventually have 68k compatible source code building blocks in asm or c/c++ for all 68k systems to just download and compile.

Not binary but source code


Steve Ferrell

Posts 424
28 Nov 2017 21:46


Asaf Ayoub wrote:

  Steve, I suggested ucLinux only because it is light, could be run in 68k Coldfire emulator to make any ports that much easier.
 
  Im talking mostly command line tools to try keep in sync with linux distros.
 
  The situation we have in OS4 land is source code being too old compilers break and never ending dependency issues.
 
  Every c/c++ code example/source ocde program in 2017 that uses C++11 or c++17 will never work on Amiga system ever until the compiler is updated.
 

I don't think most programmers are as worried about C++11/17 support as you seem to be.  Most of the programs you're referring to have their counterparts in C99. 

And you've completely missed the point.  Even if the Amiga had a C++17 compliant compiler you couldn't just simply compile Linux apps from source let alone run any of those Linux apps on an Amiga because the Amiga doesn't support many of the Linux/POSIX functions such as fork() or signals.  Those functions simply don't exist under AmigaOS 3 or 4 and have to be simulated or replaced with stub routines that do nothing. 

Running ucLinux on a Vampire doesn't do anything in regard to making the direct porting of Linux apps to the Amiga easier.  Until the OS (whether that's OS3 or OS4) gets upgraded to support the very same system calls to include fork(),glob(), globfree(), signals(), etc.... as found on Linux, you're wasting your time.  And the ixemul library only supports a subset of POSIX functions so in many cases, linking your binaries to it won't work either.  There's just too much missing functionality in OS3/4 to port many Linux apps to the Amiga.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Nov 2017 21:47


Asaf Ayoub wrote:

exactly my point any optimisations will not work on any cpu lower, especially if they are asm optimisations.

 
Please mind that this has nothing to do with a "LOWER" number.
 
The 68060 has a higher number than the 68040, 68030, 68020, but does not support all their instructions.
And the 68060 does not even support all 68000 instructions.
 
 
Asaf Ayoub wrote:

Should we have C code or assembler code compatibility back to 68000 ?
 

Sorry, this sentence makes no sense to me.
I think we have a language problem.
 
The point of C code is - that its compatible to all models.
And the compiler can make binaries suited for each cpu model from the high level code.
 
 

posts 73page  1 2 3 4