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 

Samuel Crow

Posts 424
04 Sep 2017 19:55


Creating a high-level language is a complex task.  It is so complex that even mainstream operating systems need middleware such as LLVM or GCC to build the optimizer and final code generation stages of compilation.  Since GCC is only partially available on 68k in the form of a GCC 6.3 cross-compiler in progress and complete only to 68060 and LLVM ports are less complete than even that, there needs to be some effort and/or alternatives to bring performance to the "easy" languages.

In the case of the middleware libraries mentioned above, GCC and LLVM are both written with themselves in the form of G++ and Clang++ C++ compilers.  Since the runtime support libraries for C++ are quite lacking on AmigaOS 3 and even AmigaOS 4, they might not even be readily usable on an Amiga.  In the case of the former, GCC, many UNIX-style routines are required to even get it to work resulting in IXEmul.library and LibNIX to even get it to work at all.  In the case of the latter, LLVM-RT runtimes are easier to port but still will require cross compilation in the long run because Clang and LLVM are written in C++2014 rather than the older C++ versions of GCC that the Amiga has limited access to.

As for the alternatives:

Hollywood is based on an old version of Lua which is both too old to be upgraded to LuaJIT and too customized to be updated to a newer Lua version.  What's worse, all of the plugins  and runtime libraries in Hollywood appear to be designed to compile on VBCC, a C compiler that is known to lean too heavily on the VAsm assembler to perform "peephole" optimizations on combinations of 2 or 3 opcodes at a time while not doing many of the higher level optimizations that Clang and GCC do.  The good news is that it works on the P96 framebuffer of the SAGA core bringing fancy chunky screen manipulations to the Vampire, the Lua byte-code compiler it is based on is open-source so that outside help can be brought into the picture if somebody is willing to step in to the task, and as better C compilers become available such as the GCC 6.3 cross-compiler mentioned earlier the code can get cleaner.

Amiga-specific languages such as AmigaE, AmiBlitz, and AmosPro do not generate 68080 specific opcodes and in the case of AmigaE and Blitz, use an internal assembler that cannot be easily be upgraded without a total rewrite.  AmosPro needs a new compiler anyway so a total rewrite might not be such a bad idea in its case.  Fortunately, the source code is available for all 3 of these (though I'd recommend using the ECX compiler source code for AmigaE compilation since the AmigaE compiler itself, is written in raw 68000 Assembly with no 68020+ support and minimal documentation).

Fortunately, VAsm supports the full 68080 instruction set so there is hope of being able to use it in the backend of any future language.  Its source code is available under a freeware license that allows cross-assembly from other platforms.  The downside is that it is only an Assembler and only performs small optimizations.

Where do we go from here?

As a suggestion, get familiar with cross-compiling GCC 6.3 and finding the bugs in it so that it may someday add support for registers B0-B7 and AMMX2 vectors in a 68080 backend.  The advantage to this is that it will alleviate the dependencies on VBCC and maybe Andreas Falkenhahn will be able to compile future versions of Hollywood with it.  Once C can be compiled efficiently it brings a good many other possibilities such as using GCC as a backend for other frontend languages even if they are written on some other machine such as a cheap ARM Linux box.

Since AROS is partially written in C++, it has marginally better C++ support than AmigaOS.  Also, since what isn't written in C++ is often written in C within the AROS operating system itself, an improved C compiler will bring improved performance to the AROS Kernel and support libraries as well.  The GCC support on AROS is also better than on AmigaOS because it uses its own POSIXC.library instead of IXEmul.library and has a central AROSC.library to make C programs share the common runtime library code and therefore improve the use of the code cache when running C programs.

Why it's important:

Many low-level programmers rely on capabilities of the MMU to do their debugging using tools such as MuForce, MuGuardianAngel, and the rest of the MuTools.  These may not work on AROS which has its own MMU support code independent of MMU.library written by ThoR.  Even if you stay on AmigaOS, it may be a while before the 68080's MMU gets a compatible version of MMU.library.

High level languages like Hollywood and Oberon2 can use managed code to build sandbox environments to avoid the need of the MMU based tools mentioned above.  As mentioned in the old NatAmi forum, a CHK opcode used to range check an array index requires only the initialization of a monitor program that will be called when an out-of-range index is encountered.  After that, the CHK opcode added to each array access costs only a single instruction but alleviates the problems associated with random memory trashing.  The same principle can be applied even to Macro Assembly by implementing getter and setter functions for arrays and structures and using conditional assembling to take off the "training wheels" and let it fly once debug mode is disabled and release mode is active.  Even lowly assert macros can be used to indicate tests of conditions that should never happen but sometimes do.

Conclusion:

With some smart programming techniques and some combined efforts, software can be written for and by those of us who don't have enough time to fish for all of our bugs by preventing them from happening in the first place.  By concentrating our efforts in some smart directions, the computer can be made to optimize software for you so that those that do know Assembly and write it well can concentrate their efforts on optimizing drivers and even porting tools from other platforms.

Discussion:

Questions?  Comments?  Obligatory and derogatory remarks?


Steve Ferrell

Posts 424
05 Sep 2017 00:23


Samuel Crow wrote:

Why it's important:

Many low-level programmers rely on capabilities of the MMU to do their debugging using tools such as MuForce, MuGuardianAngel, and the rest of the MuTools.  These may not work on AROS which has its own MMU support code independent of MMU.library written by ThoR.  Even if you stay on AmigaOS, it may be a while before the 68080's MMU gets a compatible version of MMU.library.

I would say that if "many" low-level programmers are relying on an MMU for debugging purposes, then they are sloppy or lazy programmers who need to go back to school to unlearn bad coding habits.  98% or more of all classic Amiga software was written on a 68000 CPU which had no MMU.  And what's to stop these "many" programmers who rely on the aforementioned tools from doing their development under UAE configured as an 030, 040, or 060 CPU or using real hardware?  And today, even most classic developers who use C/C++ won't do that development on a Vampire.  For the sake of speed and ease of use, they use a cross-compiler on Windows or Linux or develop/code inside of UAE.  So all this bitching about the Vampire not having an MMU and how it's hurting development is total BS.

I also don't consider C a high-level language.  It's an intermediate level language with assembler at the bottom, followed by C, and then C++.  High level languages are those which place an abstraction layer between the coder and the OS that's so deep that the code relies on the CPU's brute horsepower to make up for all the performance losses due to that abstraction.  Examples of these higher level languages are BASIC and Java and most other interpreted languages, even if they offer a compiler.  Most of these "high-level language" compilers aren't even real compilers.  The EXE's they produce are merely byte code with the interpreter rolled into the final EXE and therefore suffer from all the same performance issues as any other interpreted language....C# is a fine example of a high-level language that uses byte code.

So the argument for the inclusion of an 030/040/060 compatible MMU into the Vampire core isn't very important unless you're one of the fanatical purists that hangs out at A.org who has made it his life's mission to bash the Vampire for its lack of an MMU.  There are a handful of them there who make even visiting there now a painful experience.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Sep 2017 00:59


Samuel Crow wrote:

  Why it's important:
  Many low-level programmers rely on capabilities of the MMU to do their debugging using tools such as MuForce,

Sam, are forgetting that APOLLO 68080 provides this already?
APOLLO build in MPU (memory protection unit) does already allow catching illegal memory access - and reporting the failing code.




Gregthe Canuck

Posts 274
05 Sep 2017 09:20


@Samuel Crow

Good topic.

I think that 'base' C support inside GCC is important, then working on C++ and LLVM support after that. That is a good baseline.

If someone is willing to work on bounties for these updates I am prepared to chip in, as I am sure a lot of others would be.




Eric Gus

Posts 477
05 Sep 2017 09:27


I just thought I would pass this along since it was mentioned in the AMOS FB user group.. (again you would have to verify it with those folks .. I am just the messenger here), but it might ***HINT HINT HINT*** be a good idea to ensure those folks have a V4 Vampire to do this with .. **** HINT *** HINT*** HINT**

Michael Ness: Over at the AMOS Factory, we are doing some updates to the original Amiga 68k version of AMOS and are planning on targeting the vampire board in the future.



Thierry Atheist

Posts 644
05 Sep 2017 10:11


Luckily, AMOS (as is) is QUITE FAST, and multiplied by the POWER of Vampire 68080 should be able to make games that were possible by even C coded/compiled games running on 100 MHz 80486's!!!!

Is there a full set of commands that allow AMOS Pro to use the AGA chipset?

I really and truly believe that we WILL get a decent amount of CODERS returning to Amiga/Vampire!

The draw is just to strong to resist. :-) :-)


Thierry Atheist

Posts 644
05 Sep 2017 10:15


Totally agree with everything Steve Ferrell said up above.


Samuel Crow

Posts 424
05 Sep 2017 12:33


Gunnar von Boehn wrote:

 
Samuel Crow wrote:

    Why it's important:
    Many low-level programmers rely on capabilities of the MMU to do their debugging using tools such as MuForce,
 

 
  Sam, are forgetting that APOLLO 68080 provides this already?
  APOLLO build in MPU (memory protection unit) does already allow catching illegal memory access - and reporting the failing code.
 

 
  If you read every word until the end of the paragraph, I said that it will be a while until the 68080 MMU support is provided for MMU.library.  The MPU does provide functionality but until the drivers are written for it, it sits and does nothing.
 
  @Greg the Canuck
 
  Actually, GCC has come a long way since LLVM started development and its documentation has surpassed that of LLVM a while ago.  Since there is already a GCC 6.3.1 backend being worked on for the 68k, I think we could go with that and be done with it.  The only advantage of LLVM right now is its liberal 3 clause BSD-like license over the GPL 3.0 license of GCC.  Incidently, I just ran across a tutorial for making GCC frontend parsers at EXTERNAL LINK and it looks as easy as LLVM!

@Eric Gus
Mike Ness has a Vampire 500+ v2 right now so using GCC with AmosPro would break the memory bank.  I've discussed the matter with him extensively though.  Something is coming but even I am not sure what just yet.


Samuel Crow

Posts 424
05 Sep 2017 12:45


Steve Ferrell wrote:

  I also don't consider C a high-level language.  It's an intermediate level language with assembler at the bottom, followed by C, and then C++.  High level languages are those which place an abstraction layer between the coder and the OS that's so deep that the code relies on the CPU's brute horsepower to make up for all the performance losses due to that abstraction.  Examples of these higher level languages are BASIC and Java and most other interpreted languages, even if they offer a compiler.  Most of these "high-level language" compilers aren't even real compilers.  The EXE's they produce are merely byte code with the interpreter rolled into the final EXE and therefore suffer from all the same performance issues as any other interpreted language....C# is a fine example of a high-level language that uses byte code.

Hollywood works that way so it is a high-level language written in C.  The interpreter needs work though even though it has a bytecode and virtual machines for all supported platforms including Android tablets.  See EXTERNAL LINK and scroll down to the Hollywood Player heading.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Sep 2017 12:52


Samuel Crow wrote:

Gunnar von Boehn wrote:

 
Samuel Crow wrote:

    Why it's important:
    Many low-level programmers rely on capabilities of the MMU to do their debugging using tools such as MuForce,
   

   
    Sam, are forgetting that APOLLO 68080 provides this already?
    APOLLO build in MPU (memory protection unit) does already allow catching illegal memory access - and reporting the failing code.
 

 
  If you read every word until the end of the paragraph, I said that it will be a while until the 68080 MMU support is provided for MMU.library.  The MPU does provide functionality but until the drivers are written for it, it sits and does nothing.

Sam, drivers have been written and demonstrated long time ago.
Where have you been the last year?


Marlon Beijer

Posts 182
05 Sep 2017 12:54


Yeah, Bebbo is already tweaking the compiler output for the gcc 6.3 toolchain, since it was pretty garbage before. The compiled binaries for gcc 6.3 is faster than previous gcc toolchains and vbcc:
 
bebbo wrote:
Just pushed an update with plenty fixes and some improvements.
 
  Big, big, biiiiiiiiig thanks to alpine9000 who did lot's of testing, bug finding and test case building.
 
  tscpsc:  18920ms
  tscpgcc:  14120ms
  tscpvbcc: 14120ms
 
  tscpgcc6: 11560ms  (once at 12280ms )
 
 
  That's more than 5% gain!
 
  I have ideas for further otimizations in my pockets, and I'm open for suggestions (little effort -> huge effect)

 
 


Wawa T

Posts 695
05 Sep 2017 13:10


Steve Ferrell wrote:
I would say that if "many" low-level programmers are relying on an MMU for debugging purposes, then they are sloppy or lazy programmers who need to go back to school to unlearn bad coding habits.

unfortunatelly there isnt that many amiga programmers left. if you want tro drive the rest away bitching about their capabilities, be my guest, but dont complain later that none develops anything anymore.

imho debugging tools are important and lacking on amiga (or aros 68k for that matter anyway) and this shows. if debugging was not so difficult we would have a lot more software. i think i can tell something about it, debuging aros 68k for the most part.

98% or more of all classic Amiga software was written on a 68000 CPU which had no MMU.

ans it shows again, since so many programs are randomly trashing memory. just throw mutools or mungwall on and see for yourself.

And what's to stop these "many" programmers who rely on the aforementioned tools from doing their development under UAE configured as an 030, 040, or 060 CPU or using real hardware?

perhaps not that much. they would have to refrain to nojit emulation to enable the mmu, im not sure if winuaeenforcer works with it, im doing it nevertheless. and they couldnt test their apollo specific inlines that way. so there probably wouldnt be the certanity, that the program doesnt trash the memory anyway.

And today, even most classic developers who use C/C++ won't do that development on a Vampire.  For the sake of speed and ease of use, they use a cross-compiler on Windows or Linux or develop/code inside of UAE.  So all this bitching about the Vampire not having an MMU and how it's hurting development is total BS.

i dont know what development you are soing, but sebugging aros68k i can confirm that i am compiling under linux, but i need to test under 68k, be it emulation or real hardware, which is more accurate and inavoidable in many cases, such as device drivers and many higher os layers, such as related to graphic subsytem. if this was such a cakewalk to do, we would have fast and reliable drivers and libraries long ago.
 
So the argument for the inclusion of an 030/040/060 compatible MMU into the Vampire core isn't very important unless you're one of the fanatical purists that hangs out at A.org who has made it his life's mission to bash the Vampire for its lack of an MMU.  There are a handful of them there who make even visiting there now a painful experience.

i give you that there are persons with an obvious agenda out there. and i dont advocate a backwards compatible mmu for the sake of it, especially i dont own vampire hardware myself. but i understand considerations about debugging practice.



E Penguin

Posts 46
05 Sep 2017 13:15


I was wondering about this the other day - how I could use Vampire-specific instructions in Blitz2. Is it possible to write some general purpose libraries in asm which can be used by existing higher-level languages through some interface code? I realise it won't be as good as using the features directly, but would be better than not using them at all.

I have no idea how I would use such a library in Blitz2 but I believe it can access libraries somehow. Haven't got that far yet. Certainly would be doable through C though, if sufficient headers are provided.


Samuel Crow

Posts 424
05 Sep 2017 13:27


Daniel Lakey wrote:

I was wondering about this the other day - how I could use Vampire-specific instructions in Blitz2. Is it possible to write some general purpose libraries in asm which can be used by existing higher-level languages through some interface code? I realise it won't be as good as using the features directly, but would be better than not using them at all.
 
  I have no idea how I would use such a library in Blitz2 but I believe it can access libraries somehow. Haven't got that far yet. Certainly would be doable through C though, if sufficient headers are provided.

Libraries can be written in Assembly or C.  To access the AMMX or AMMX2 features and base registers it would have to be written in Assembly using VAsm since it's the only environment that supports the 68080 at this point.  It would be nice if C supported those features as well though.  Once written and debugged, shared libraries can be accessed by almost any language on the Amiga!


Samuel Crow

Posts 424
05 Sep 2017 13:29


Gunnar von Boehn wrote:

Sam, drivers have been written and demonstrated long time ago.

Where have you been the last year?


Tinkering and being glad the Amiga is in better hands than mine, apparently.


E Penguin

Posts 46
05 Sep 2017 14:42


Maybe the effort should focus on creating shared libraries as a first step, before having native compiler support. AMMX.library?


Samuel Crow

Posts 424
05 Sep 2017 15:10


Daniel Lakey wrote:

Maybe the effort should focus on creating shared libraries as a first step, before having native compiler support. AMMX.library?

Wrapping each individual opcode in libcalls would kill the performance advantages due to calling overhead.  Vector units are exceptionally good at handling large streams of data at once.

Of course hand-optimizing code tends to be more difficult than just adding spill-slots to a compiler backend so that the added registers just are treated like fast storage for frequently used values.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Sep 2017 15:59


Samuel Crow wrote:

just adding spill-slots to a compiler backend so that the added registers just are treated like fast storage for frequently used values.

Yes, you are right - more register will make the system faster.

And, yes for a compiler making use of more registers is easy.

And _ALL_ 68K instructions can use and utilize the more register of APOLLO.



Fernando Pereira

Posts 68
05 Sep 2017 18:10


My hope and enthusiasm flies out the window whenever I read about developing for my favorite platform of all time, the Amiga; all this mishmash of terms and fragmentation of tools... I'm a fluent C# coder bearing vast experience towards designing user friendly UI but I feel like a complete moron whenever I try to embrace Amiga development.


Steve Ferrell

Posts 424
05 Sep 2017 18:24


wawa t wrote:

  unfortunatelly there isnt that many amiga programmers left. if you want tro drive the rest away bitching about their capabilities, be my guest, but dont complain later that none develops anything anymore.
 

 
  I seriously doubt that any of my comments will drive assembly language programmers away from programming.  If you really believe that then you think much too highly of me.  Most assembly language programmers have simply moved on to higher level languages such as C because assembler can be so time consuming compared to other languages. 
 
If anything, I'm seeing more interest in assembly programming (and C/C++) since the Vampire's inception.  Jari's softFPU is one example and Flype has been doing some exceptional assembly work as well. 
 
My latest foray into classic Amiga development was just a few months ago after taking a 24 year break from any Amiga development.  I conducted it all using a real A1200 and Lattice C 6.58.  EXTERNAL LINK   
It was a great experience but compiling was painfully slow at times so in the future I will use the AmiDevCPP cross-compiler on Windows:  EXTERNAL LINK   
To test the EXE's I'll simply have the compiler's output place the binary into a shared WinUAE folder on my development system and run AmiDevCPP and WinUAE concurrently. That way I can test immediately after a compile/recompile.
 
 

posts 80page  1 2 3 4