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!

High Level Languages: How to Proceedpage  1 2 3 4 

Steve Ferrell

Posts 424
08 Sep 2017 18:29


After a little more thought I've come to the conclusion (which may be wrong BTW) that C/C++ will most likely receive compiler support for the Vampire's new features long before the higher level languages receive it.  Once assembly language support for AMMX and other features occurs for VASM or DevPac, there isn't much more that's required to add these features to C/C++. 
   
The C/C++ compilers can use the same link time libraries used by the assembler packages, which in the case of AMMX already exist, so really all that's additionally required for C/C++ support are the include files and some documentation.  For folks not familiar with C/C++, the include files would contain the AMMX function prototypes, the parameters that are passed to and from those functions and the data types for those parameters and functions and a few other bits.
   
I suppose it's a natural progression and once the new features get added to C/C++, some savvy C/C++ programmers will then create the tools and libraries for the next languages that sit higher up on the ladder such as the various BASIC's and other higher-level languages.
   
It may be possible to extend Amos (and other compiled high-level languages that aren't using byte code) in the same manner as the C/C++ compilers.  I'm jut not familiar enough with Amos and those other languages to provide any insight.
   
I'm also guessing that the Apollo Vampire team has a programmer who is skilled in both assembler AND C/C++ who will provide the appropriate include files and link liibraries to developers once they've completely documented AMMX. I'd be curios to know which C/C++ compiler, if any, they will be targeting.
   
How about it Gunnar?  Is the Vampire team going to provide any C/C++ tools for the Vampire or will they only support assembly tools and expect someone outside the team to provide/develop C/C++ compiler support for the Vampire's new features?


Samuel Devulder

Posts 248
08 Sep 2017 19:09


Steve Ferrell wrote:
The C/C++ compilers can use the same link time libraries used by the assembler packages, which in the case of AMMX already exist, so really all that's additionally required for C/C++ support are the include files and some documentation

Correctly supporting 68080+AMMX in C/C++ is not a matter of using a suitable optimized library. How such library be optimized if a compiler doesn't do it in the first place? (not every libray can be hand-optimized)
   
Actually, correctly supporting the 080+AMMX, require that the compiler be completely re-designed to deal with new way of coding for the 68080: better instruction scheduling to enhace superscalar, replace std 68k 2 args operations by the 3-args AMMX parallel ones, etc. It a complete re-design of traditionnal C compilers that must be done.
     
Modern C compilers for other platforms use these SSE/MMX optimization extensively. For instance in my C test with the fact() function, I was surprised that on x64 gcc was able to use SSE instructions where I didn't suspect it was possible. The resulting ASM code doesn't look anymore like the C code, but yet it is a correct translation that works faster than the naive X86 assembly version I was expecting.
     
I wish we can get a C compiler for the 080+AMMX that can optimize this much and will not be stuck with plain old fashioned 680x0 optimizations.
     


Steve Ferrell

Posts 424
08 Sep 2017 20:20


Samuel Devulder wrote:

 
Steve Ferrell wrote:
The C/C++ compilers can use the same link time libraries used by the assembler packages, which in the case of AMMX already exist, so really all that's additionally required for C/C++ support are the include files and some documentation

    Correctly supporting 68080+AMMX in C/C++ is not a matter of using a suitable optimized library. How such library be optimized if a compiler doesn't do it in the first place? (not every libray can be hand-optimized)
       
    Actually, correctly supporting the 080+AMMX, require that the compiler be completely re-designed to deal with new way of coding for the 68080: better instruction scheduling to enhace superscalar, replace std 68k 2 args operations by the 3-args AMMX parallel ones, etc. It a complete re-design of traditionnal C compilers that must be done.
         
    Modern C compilers for other platforms use these SSE/MMX optimization extensively. For instance in my C test with the fact() function, I was surprised that on x64 gcc was able to use SSE instructions where I didn't suspect it was possible. The resulting ASM code doesn't look anymore like the C code, but yet it is a correct translation that works faster than the naive X86 assembly version I was expecting.
         
    I wish we can get a C compiler for the 080+AMMX that can optimize this much and will not be stuck with plain old fashioned 680x0 optimizations.
         
 

 
Wait a minute......you say that adding AMMX support to existing C/C++ compilers is impossible because the compilers need to be updated to support optimization of AMMX?.....That simply isn't true
 
The process I described earlier for adding AMMX support to existing C/C++ compilers is exactly the same process regardless of whether we're talking about AMMX, SDL, or OpenGL.  Code is written in assembly or C/C++ to create a shared library, an object file or a static link library that can be called or linked with later on.  That's been the process for extending C's capabilities since its inception.
 
I never said anything about modifying compilers to optimize AMMX code.  I'm talking about adding the ability to call AMMX enabled functions from C using standard C calling conventions to perform operations using AMMX instead of using the older, slower, standard C functions that are built into the compiler. I'd much rather call an AMMX function from C that performs vector normalization than doing the same thing using the existing C and 68882 math libraries.
 
C/C++ compilers could take advantage of AMMX now even if they don't have the ability to optimize the AMMX portions of the code.  Optimizations by the compiler can be added later on, that's usually what happens when new extensions are written.  Even in the world of SSE on Windows that's how it worked.  Initially the programmer had to either manually write inline-assembly or import object-code from an external source. Later the Visual C++ Processor Pack added SSE2 support to Visual C++ and MASM.  It's no different here.
 
 


Samuel Devulder

Posts 248
08 Sep 2017 20:47


The process I described earlier for adding AMMX support to existing
    C/C++ compilers is exactly the same process for extending the instruction set for C/C++ compilers regardless of whether we're talking about AMMX, SDL, or OpenGL.

  No, AMMX is not just about a set of predefined function like SDL or OpenGL. These are two different and distinct matters. AMMX is low-level, and SDL or OpenGL high-level.
 
  In "hi-level" C code you should'nt call low-level (ie. AMMX) instructions in-place. Instead, AMMX instructions are to be produced by the C compiler when optimizing basic C statements, for instance with loop unrolling.
 
  AMMX is not just a set of predefined library procedures. Doing this is contrary to the higher-level abstraction. It is terribly inefficient and very limited. For instance, you won't have access to the various addressing modes the AMMX provides. Imagine that there is a LOAD_Aiplus_Ej(i,j) procedure that invoke "LOAD Ai+,Ej" to load 16 bytes from memory pointed by Ai into register Ej. Very flexible, very AMMX-style, isn't? Great! But how would you know that the local pointer you intend to read from is hold in register A1 A2 or A4 ? Which 'i' value should you pass to the procedure? Impossible to know :( At best you'll have to make this more abstract and provide a LOAD16(void*, long long) procedure which will be replaced by 4 or 5 AMMX instructions. This would'nt be real AMMX anymore but a higher level abstraction. You would'nt use the full power of AMMX this way.
 
 
(..)Optimizations by the compiler can be added later on, that's usually what happens when new extensions are written(..)
Right, except this isn't a simple addition or extension that is required, but a complete rewrite of the compiler targeted for AMMX. It is a very huge effort. I mean, you cannot fiddle with an existing compiler producing good 68k code to make it produce good AMMX code. You'll have to make a new one and consider the AMMX support from the very beginning of the design.

Right now, the correct way to support AMMX with C code is to inline the assembly-language code using the __asm__ __inline__(code) that most C compiler provide. This is assembly-language embeded in C, not plain C.


John William

Posts 563
08 Sep 2017 21:20


That means high level languages like AMOS and AmiBlitz also need to be rewritten to support AMMX technology. To be honest...any developer who develops apps or games using high level language will never be able to use AMMX technology. They would need to know assembly and embed that in their projects for AMMX to be implemented.


Steve Ferrell

Posts 424
08 Sep 2017 21:28


Samuel Devulder wrote:

                        I mean, you cannot fiddle with an existing compiler producing good 68k code to make it produce good AMMX code. You'll have to make a new one and consider the AMMX support from the very beginning of the design.
                        Right now, the correct way to support AMMX with C code is to inline the assembly-language code using the __asm__ __inline__(code) that most C compiler provide. This is assembly-language embeded in C, not plain C.
                       

                   
Thanks but I don't need a lesson in C or __inline coding.  I'm well acquainted with C/C++ and develop LIDAR applications for OSX, Windows and Linux.  EXTERNAL LINK 
                       
I never said anything about producing fantastic or even "good" AMMX optimized code.  Even un-optimized AMMX code is going to run rings around standard code in most cases.  When MMX/SSE was introduced on AMD/Intel CPUs, initially x86 compilers didn't directly support nor optimize MMX/SSE code.  The features were added incrementally in what I like to call a cludge, and the added features/extensions had to start somewhere.  Existing compilers were NOT thrown out and rewritten from the ground up just because MMX/SSE had been developed, although this occurred for some compilers later on.  Microsoft sent C/C++ developers header files, static libs and obj files to get them started until Visual Studio could be updated with native support AND optimization so that they didn't have to resort to using __inline assembly. It was known as the Visual C++ Processor Pack. It provided access to the new instruction set in the form of C intrinsics. 
             
I understand that a new 68K compiler designed from the ground up with AMMX optimization in mind is the IDEAL route, but until that happens (and it may well never happen), it would be great if C/C++ developers could start taking advantage of AMMX now without using inline assembly, just as developers did with Visual Studio in the early days of MMX/SSE.  Rewriting compilers from the ground up is not a requirement as you've stated.
               
I'm just wondering if the Vampire Team has a road map for AMMX that is similar to how MMX/SSE was rolled out (aka release some headers, objs and link libs) or if that road map even exists.  They may have no intention of promoting AMMX on C/C++ whatsoever, and that's fine, but it would be nice to know.
                       
It would be great to leverage at least portions of AMMX as a C/C++ developer even if I have no way of optimizing the output for best performance because in most cases the AMMX code will still outperform the older tool set by a large margin.
                       


Eric Gus

Posts 477
09 Sep 2017 06:54


As a part time programmer .. I am **excited** to start coding again on the Amiga with AMOS .. even if its lacking any sort of update.
 
  I am not excited or even motivated to use C or C++, LUA or anything else..
 
  And there is for no logical or technically valid reason for it ... it may be old, non optimized etc but that matters little.
 
Part of it is nostalgia for me, I have a lot of fond memories of coding in AMOS with its "unique" IDE  .. its all part n parcel for me... Its also one of the easiest to program in as others have stated .. and when I do coding on the Amiga, I am doing it for fun an enjoyment.. not for professional reasons.  I suspect many others will also be as well.


Steve Ferrell

Posts 424
09 Sep 2017 07:12


eric gus wrote:

  As a part time programmer .. I am **excited** to start coding again on the Amiga with AMOS .. even if its lacking any sort of update.
   
 

 
AMOS was pretty popular among Amigans back in the day so it will happen, hopefully sooner rather than later.  I would not be surprised if there was someone already working to patch AMOS and add the necessary hooks for 68080, SAGA and AMMX.
 
As a side note, I did some more digging and found that Icomp.de, Jens Schonfeld's company, has decided to sponsor the C compiler VBCC. EXTERNAL LINK   
They are already adding 68080 support which is good news not only for C programmers but for those programmers who prefer higher level languages who will be relying on C and assembly programmers to provide them with patches and hooks for 68080 and AMMX.  Not sure how I missed this post back in May of this year:  EXTERNAL LINK


Thierry Atheist

Posts 644
09 Sep 2017 07:30


eric gus wrote:
As a part time programmer .. I am **excited** to start coding again on the Amiga with AMOS .. even if its lacking any sort of update.

THAT is a tragedy of EPIC proportions!!!!!
eric gus wrote:
And there is for no logical or technically valid reason for it ... it may be old, non optimized etc but that matters little.

1) The 68080 is SUCH the speed demon, that AMOS will run faster than coding in assembler, probably even on a 16 MHz 68020!!!
2) AMOS is compilable, adding some extra speed. Then it should be faster than that 68020.

Okay, okay, it's wild speculation on my part.
eric gus wrote:
Part of it is nostalgia for me, I have a lot of fond memories of coding in AMOS with its "unique" IDE  .. its all part n parcel for me... Its also one of the easiest to program in as others have stated .. and when I do coding on the Amiga, I am doing it for fun an enjoyment.. not for professional reasons.  I suspect many others will also be as well.

It really IS FUN!

Writing programs can even be done, as though you're playing games... "I wonder if I'm able to do that?" It doesn't have to just be "I will write code, it WILL DO task 'xyz'".

There's "no thinking" involved on a ridiculous amount of elements that some other languages force you to do.

I took a computer course in 1985 or 1986. So, get this, they were teaching Pascal. I couldn't find ONE SINGLE INSTRUCTION in the user manual that told me how to control graphics, so that I could place single pixels on the screen. The instructor wouldn't tell me how to do it. His reasoning for this was "in the real world, you'd have to find out for yourself".... In that case, WHY'D I PAY HIM $3,600???? Also, he refused to tell me how to put a character in the bottom right space without triggering a carriage return that would raise every line one up and the top line off of the screen!!!!! I would bet that, maybe even until TODAY, he didn't and still doesn't know the answer to at least that last question!!!! This was using IBM clones/ms-dos era.

In AMOS, only if it doesn't work, is it "wrong".


Thierry Atheist

Posts 644
09 Sep 2017 07:59


Thierry Atheist wrote:
In AMOS, only if it doesn't work, is it "wrong".

I was looking at this statement I made, and at first, it looks stupid.

So, I feel that I need to explain it. (Still might sound stupid.)

1) I'm talking about, people always say "don't use 'GOTOs'". Well I want to. I have, after many people have told me that, figured out how to get out of it in almost every case, but sometimes, as a standby, it's comforting to know that I can just whip it out and use it. You have to alter your style of coding to get out of the trap of needing to use goto everywhere. I admit, things work out better using GOTO to a minimum.... but, I would have a MENTAL BREAKDOWN if it was GONE!!!!!

2) You don't need to declare variables, that's a HUGE THING for me. I would HATE to have to do that, ABSOLUTELY! Totally throws me out of my coding game to go back to the top, declare something, scroll back down and continue working.

3) I constantly see people talk about which library they did or didn't open, or file wasn't included, or "did you use ___ switch when compiling"? TOO MUCH BRAIN PAIN!!!!!!

4) If you make "spaghetti coding" it's YOUR problem, and no one else's. Most C coders seem to be passing their code around and it's all about "documentation, documentation, documentation". And adhering to some strict practices, protocols. AMOS is MUCH MORE PERSONAL....

Just like I like to refer to the AMIGA/Vampire as the WORLD'S LAST PERSONAL COMPUTER!!!!!!!

(If this makes any sense at all, I hope I came up with enough examples.)


Eric Gus

Posts 477
10 Sep 2017 09:10


Steve Ferrell wrote:

  They are already adding 68080 support which is good news not only for C programmers but for those programmers who prefer higher level languages who will be relying on C and assembly programmers to provide them with patches and hooks for 68080 and AMMX.  Not sure how I missed this post back in May of this year:  EXTERNAL LINK 

Oh thats great news.. !


Samuel Crow

Posts 424
10 Sep 2017 10:09


Keep in mind that GCC stands for GNU Compiler Collection.  New language front-end parsers can be added successfully to it.  The main reason it's used for cross-compilation is that it uses a large amount of memory.  It'll take a major overhaul to make it work on a smaller Amiga but it is still possible nonetheless, especially on a V4.


Steve Ferrell

Posts 424
10 Sep 2017 18:25


Samuel Crow wrote:

  Keep in mind that GCC stands for GNU Compiler Collection.  New language front-end parsers can be added successfully to it.  The main reason it's used for cross-compilation is that it uses a large amount of memory.  It'll take a major overhaul to make it work on a smaller Amiga but it is still possible nonetheless, especially on a V4.
 

 
New front-end parsers can be be added to any C/C++ compiler but the chances of AMMX extensions being added to GCC are slim to none. 
 
At least with VBCC the process to add Vampire support is underway and Jens Schonfeld is sponsoring the effort.  VBCC is also a native Amiga compiler with resource requirements that are much less than those of GCC.
 
As with VBCC, I think the only way that GCC will ever achieve AMMX capabilities is thru some sort or sponsorship or a kickstarter campaign.  Even then there might not be enough interest to get the sponsorship levels to the point where someone could or would take on a project of that scope. 

I hope I'm wrong and that some talented programmer already has plans or is already working to add AMMX support to GCC.
 


Edgar Fink

Posts 47
11 Sep 2017 09:05


@samuel crow: I am already using gcc on an Amiga using the ADE environment (gcc version 2.95.3) both in FS-UAE and on A1200. Or did you mean, it'll take a major overhaul to add AMMX to GCC?


E Penguin

Posts 46
11 Sep 2017 10:30


Samuel Devulder wrote:

  AMMX is not just a set of predefined library procedures. Doing this is contrary to the higher-level abstraction. It is terribly inefficient and very limited. For instance, you won't have access to the various addressing modes the AMMX provides. Imagine that there is a LOAD_Aiplus_Ej(i,j) procedure that invoke "LOAD Ai+,Ej" to load 16 bytes from memory pointed by Ai into register Ej. Very flexible, very AMMX-style, isn't? Great! But how would you know that the local pointer you intend to read from is hold in register A1 A2 or A4 ? Which 'i' value should you pass to the procedure? Impossible to know :( At best you'll have to make this more abstract and provide a LOAD16(void*, long long) procedure which will be replaced by 4 or 5 AMMX instructions. This would'nt be real AMMX anymore but a higher level abstraction. You would'nt use the full power of AMMX this way.

A good library wouldn't focus on exposing the low-level AMMX opcodes, rather it should provide useful utilities for doing a "thing" that benefits from AMMX. Matrix manipulations. Polygon filling. Fourier transforms. Focus first on what AMMX can be used for, rather than exposing generic AMMX statements. Certainly, it reduces the flexibility to whatever the library implementer can think of, but it's better than nothing.


Samuel Crow

Posts 424
11 Sep 2017 11:47


Edgar Fink wrote:

@samuel crow: I am already using gcc on an Amiga using the ADE environment (gcc version 2.95.3) both in FS-UAE and on A1200. Or did you mean, it'll take a major overhaul to add AMMX to GCC?

I was talking about GCC 6.3.1 because it generates better code now that Bebbo on EAB is updating the 68k backend.  Since GCC supports auto vectorization, AMMX could be used better and more often than on a lighter compiler like VBCC.

That said, I would welcome an OpenCL implementation regardless of the compiler.  That's what will be the parallel processing power of AMMX2.


Fernando Pereira

Posts 68
11 Sep 2017 12:05


eric gus wrote:

  As a part time programmer .. I am **excited** to start coding again on the Amiga with AMOS .. even if its lacking any sort of update.
   
    I am not excited or even motivated to use C or C++, LUA or anything else..
   
    And there is for no logical or technically valid reason for it ... it may be old, non optimized etc but that matters little.
   
  Part of it is nostalgia for me, I have a lot of fond memories of coding in AMOS with its "unique" IDE  .. its all part n parcel for me... Its also one of the easiest to program in as others have stated .. and when I do coding on the Amiga, I am doing it for fun an enjoyment.. not for professional reasons.  I suspect many others will also be as well.
 

 
  I also look at Amos as the main candidate, followed by AmiBlitz.
 
  Can someone describe me the differences between the two? I would like to hear your thoughts regarding:
 
  - Easiness to use.
  - Which one is more capable.
  - Performance differences.
  - UI development etc.
 
  Thank you!
 
 


Samuel Crow

Posts 424
11 Sep 2017 14:22


Fernando Pereira wrote:

  I also look at Amos as the main candidate,
  Can someone describe me the differences between the two? I would like to hear your thoughts regarding:
 
  - Easiness to use.
  - Which one is more capable.
  - Performance differences.
  - UI development etc.
 
  Thank you!

AMOS is easier.  Blitz is faster and supports AGA.  AMOS has a friendly editor and IDE.  Blitz uses and produces Intuition interfaces.  Any questions?  :-)


Fernando Pereira

Posts 68
11 Sep 2017 20:15


Samuel Crow wrote:

Fernando Pereira wrote:

    I also look at Amos as the main candidate,
    Can someone describe me the differences between the two? I would like to hear your thoughts regarding:
   
    - Easiness to use.
    - Which one is more capable.
    - Performance differences.
    - UI development etc.
   
    Thank you!
 

  AMOS is easier.  Blitz is faster and supports AGA.  AMOS has a friendly editor and IDE.  Blitz uses and produces Intuition interfaces.  Any questions?  :-)

Argh! I wasn't aware Amos didn't support AGA! That is a knife in the chest. How much faster is Blitz compared to AMOS?


Samuel Crow

Posts 424
12 Sep 2017 18:15


The Blitz compiler is much faster than Amos Professional because it supports register loading optimization while the Amos compiler dumps every variable to RAM between uses.

posts 80page  1 2 3 4