Thanks for the info and opinion(s) samurai.

The whole point of my remarks concerning incompatibilities like mentioned was that a) there is no point in trying to convert those as they would only run on their respective platform(s) that support that kind of functionality and b) the ones that are written friendly enough would probably benefit more from having a source so that it can be re-compiled using another backend in the compiler that produces more acceptable/friendly code/source.

Unfortunately i still haven't got any (hands on) experience with llvm to make a fair judgment for projects like bernd's (so i stick to what i do know ).

Quote:

BLITZ mode detected... custom AGA or ECS hardware not found.

Quote:

It wouldn't translate to x86 or ARM due to endianness issues. Nor PPC due to alignment issues.
Quote:

Why waste time with an x86-specific compiler when a more general form may be possible using additional backends for the compiler. PPC AROS anyone?

Quote:

I do. It's bit-rotted but may still be salvaged.

Mike "Sidewinder" Ness now has two jobs now and no time to redo his previous work, much less make a port from Linux to AROS as a phase 2 bounty.

I have a dead-end job but after Mike had so much hassle with the initial code generator, I'd need a bigger bounty than $500 to do the work. There's a huge gulf of difference between 2.9 and 3.x including changes to the bitcode format.

Quote:

Cross assembling is certainly possible with LLVM. There may need to be an optimization pass made to exclude unused parameters from the Call instruction although it's easier to simulate the original 8 data registers and 7 address registers with global varaibles that can be register loaded by the optimizer. Tricks with the stack pointer may be more difficult though, since IR is higher level than true Assembly code. Also tricky may be endianness issues and knowing when to and when not to use the BSWAP intrinsic.

An easy way to implement cross-assembly is to make each opcode a subroutine that calls another subroutine for the addressing mode and give them all "available_externally" linkage type.

Quote:

First, it's a code generator rather than a port. Port suggests that it actually runs on AROS and it doesn't. It runs on the existing LLVM-supported platforms but generates code for AROS using cross-compilation.

Second, it's version 2.9 of LLVM while the current stable release is 3.4.2 and version 3.5 is coming out soon.

Quote:

The same as C does it. You use the C calling convention to pass parameters to each subroutine. This is different from Assembly where you only use registers or the stack to pass values in and out of subroutines. The reason for this is that there are different processors supported by the IR.

Hi bernd,

please forgive my ignorance, but how would one be able to translate this compiled code ?


Even stronger, it might be harder to detect such produced code when translated into llvm.

It would imho be easier to change the compiler backend of blitz to produce something more meaning full (then it does right now).

Of course, that leaves you with compiled programs which have no source-code, but running that without emulator (or classic machine) ?

It would imho be easier to analyze the 68k produced code and translate that back into blitz source by analyzing (used by amiblitz) patterns. Or perhaps even directly translate into x86 counterparts.

sorry, i don't have any specific information about the status of the llvm compiler (for aros).

My idea is that amiblitz programs run without 68k emulator that i translate the asm source output with a crossassembler to LLVM IR Code. amiblitz use not much diffrent 68k instructions so is not so much work. I see only example with X86 instructions to translate to LLVM IR

http://llvm.org/devmtg/2013-04/bougacha-slides.pdf

an X86 instruction

sub [rbx + 8], rax

is for example translate to this LLVM IR Code

%1 = add i64 %rbx1, 8
%2 = inttoptr i64 %1 to i64*
%3 = load i64* %2
%4 = sub i64 %3, %rax2
store i64 %4, i64* %2

Is the LLVM Port of AROS able to create then executable programs, when write a 68k asm source crossassembler to LLVM IR instructions ?

And how i need do AOS calls, open libs etc ?

Thanks, it sounds like a developers dream come true.
In the end it sounds like Aros will not be left out too much when it comes to getting apps.
At least the tools are there.

Ummm... Sort of.

Here's what it is:

CLR can be built on top of LLVM. LLVM is more low-level than CLR. The statically compiled version of Mono uses LLVM as its code generator.

LLVM is a compiler building framework. You can build virtual machines like Mono or Java on top of it. You can also use it to build a C++ compiler like Clang++. It's also used as a shader optimizer and JIT in Mesa. Although these projects are built on top of LLVM, LLVM itself is just a tool in the chain.

The most blatant use of LLVM would be PNaCl which applies a target-neutral processor architecture to the original NaCl runtime library so that it can run on any 32-bit little-endian processor under the Chrome web browser.

Some people on this board have high hopes that closed-source projects can be made to work on multiple architectures using AROS as its runtime library. This of course will require the 32-bit little endian (LE32) neutral target from PNaCl which has already been pushed upstream to the LLVM source in version 3.0.

I'm one of those people hoping that software written for the LE32 target under AROS will allow people running x86 and ARM AROS to run the same code from the same install media. Only the installer will be different between the two architectures because it would have to translate from the LE32 binaries into ARM or x86 binaries.

Here's what it isn't:
LLVM doesn't contain enough runtime libraries to do much. In other words, the binaries written in LE32 still will depend on the C runtime libraries in AROS and software will be written in the C language using the Clang compiler or derived languages like Lua and Hollywood. LLVM adds neither .NET nor GNU Classpath nor any runtime engine to AROS. That still has to be added by ambitious programmers later on.

LLVM doesn't magically add endian awareness to source codes. Even with the LE32 target, only little-endian code will run on LE32 targets. Getting big-endian code to run on big-endian processors such as 68k Amiga or PPC will require the development of a BE32 big-endian target to be modified from the LE32 target. And getting LE32 compiled code to run on a big-endian platform will require an additional endian-conversion linker library to do all the endian swapping like the old x86-BE version of AROS from years ago. (Fortunately, LLVM DOES support link-time optimizations to eliminate redundant double-endian swaps.)

I hope this clears things up for you.

To sound like a broken record...
Is the LLVM similar the MS CLR?
Looking at a Win8 pdf, they can use java-script for apps.
If I understand it correctly.
What do you think?

Phase 1 is complete. Phase 2 may take some time and energy. Possibly moreso than phase 1 did.

Bump