GCC 13.2 as a shared library?

I posted the following message on EAB but thought it might find a better reception here:

I've been kicking around the idea of using the LibGCCJIT frontend on Bartman's GCC 13.2 patch version to provide a competitive backend and optimizer for Amiga-specific programming languages. I had AmigaE in mind (using my fork of ECX) but any language that doesn't need a huge runtime or has the runtime already written (like AmosPro Unity) would be a possible candidate.

Also, the Library version of GCC would be reentrant because the LibGCCJIT frontend allows the rest of the compiler to be written as position independent code.

Part of the reason I'm writing this post is that I need at least one accountability partner. My ex-wife always recommended that I shouldn't go lone-wolf into a large project only to face burnout.

Another reason is that GCC is available on all next-gen Amiga-like platforms with a new enough version to recompile using the LibGCCJIT frontend, thus allowing them to use common Amiga programming languages.

Is anybody interested?

@Samurai_Crow

libGCCJIT sounds interesting. It looks like it could also be useful for JIT compiling code written in a game engine's scripting language.

Alas, I'm unlikely to have time to play with this directly.

Hans

@Hans

Not only does it support JIT compilation, but it can compile to disk like conventional GCC. Unlike other attempts, such as LLVM, it's compatible with C ABIs and doesn't require C++ runtimes.

@Hans wrote:

Quote:Hmm, how about JavaScript? Thinking about potential web browser usage.

No idea if I'm talking utter rubbish.

Best regarrds,

Niels

@nbache

WebAssembly might be more promoising at this point. There is an experimental JavaScript to WebAssembly transpiler/translater on GitHub that runs 3 times faster than the fastest JavaScript JIT on average just by doing AOT compilation instead. W2C2 translates to C89 from WebAssembly that could be optimized better by leaving out the C intermediate stage.

I don't want to get too involved at this point though. Especially not working alone.

AmigaE and WebAssembly are statically compiled but JavaScript is not. The DOM of a browser might be a bridge too far as well.

The first step is just trying to build the library, right?

@nbache
Quote:
That could be done. However, the difficult part is the massive Javascript browser runtime libarary, with all its interactions with the browser.

I wonder if it would be useful to JIT recompile PowerPC code to fully native PowerPC SPE code. That would be very useful for the A1222.

I'm guessing that its effectiveness would depend on whether the JIT's intermediate representation can match PowerPC instructions.

Hans

@Hans

I’m pretty sure AmigaOS4.1 for A1222 has JIT compilers for PowerPC code already, or at least some type of recompilation stage.

@Samurai_Crow

Quote:

Not really AmosPro is written in 680x0 assembler, not C code, and AmosPro libraries bang hardware, you can’t use it on anything else computer whit AGA chipset or a emulator.

Unity is nice word! but what Unity was he talking about.
Only unity of the old obsolete Amiga chipset.

@nbache

JavaScript JIT can only be used on JavaScript language, JS is lot more secure the C code, as only has access to Web Engine, not your computer.

C code has many libraries that’s not cross platform, a lot of code, can’t the recompiled, the code will need to port to the platform itself.

its not new thing, sunrpc has doing distributed recompilation to harness the computer power of network cluster. Advantage of dynamic recompilation is that target system can have different CPU types. I assume that target os is similar UNIX systems, like Solaris (SPARC, x86-64, IA-32, PowerPC).

Typical language used in games is lua, it provides a way to create scripts for AI’s, and level logic.
remember messing around with that in Battle Forge. Fun game, sadly a pay to win game, with lack of levels, at least they provided way to make custom levels.

A RunTime can provide security, as its can provide interface between program and OS, not having the runtime, means you are interface directly with the OS and your local files / local network.

@LiveForIt

Quote:
AmigaOS 4 has a Load-Time-Emulator (LTE) for floating-point instructions. However, having a full JIT that handles all instructions would be better.

The SPE doesn't have dedicated FPU registers, and uses 64-bit General Purpose Registers (GPRs). Those are the same registers that are used for integer operations and everything else.

A full JIT could do complete register reassignment, thereby eliminating the overhead of an emulated FPU register file.

Hans

@Hans

Quote:

Not sure how you map that without moving registers into memory as backup. The SPE and FPU seams nothing similar.
Using SPE means you have a lack of CPU registers, no longer having the float registers.

SPE is a lime, now you need to learn who to make a lemonade.

@rjd324Quote:

That'll be the easy part but yes, building the library is the first step. I just need somebody who has a use for it to step up because that'll be the test case.

@LiveForIt
Re:AmosPro Unity

Didn't you write chipset emulation libraries for PPC to use? It should need a recompile to use them but that's what GCC is for.

By the way, AmosPro Unity supports AGA by using a shared library for the runtimes. I wouldn't want to waste too much time but a shared library based on AOZ for RTG might be useful if it were written in something other than JavaScript.

@Samurai_Crow

Quote:

Yes played with different aspects, but its not complete chipset emulator.

The work on Nalle Puh covers Paula, and CIAA/CIAB chips (timing is affected by CPU load, so not so good, I should have look at that code again), as well as the blitter, it does not cover Denice, it can’t display anything. For example was able to get sound in Deluxe Galaga AGA, but can’t see the graphics.
(blitter emulation does not support line mode, its based on blitzen code, tried reuse code from euae but did get it working correct.)

The Other chipset emulation project related to cooper emulation only works, with code that’s rewritten to use it, not particularly useful. Assembler can be converted into macros, CPU registers can be unions or c++ classes, covering different storage sizes. The conversion job was manual labor.

Of course before that I did write fake screen mode emulator, but that did not cover cooper (perhaps some support for colors, but that was all), at least not fully, the aim was simply to provide missing modes, like dbntsc and dbpal, etc, and render the graphics faster.

Some projects where partially successful, but not great, and it show it was room for improvements in backwards compatibility. I think you need really good understanding of this stuff, then you can be more successful, the lack of test cases, unit testing, and understand of chipsets was major hindrance.

Perhaps some stuff can be combined, but the overall overhead of display emulation will, result in relative huge CPU usage, rendering the idea kind of useless, considering you already have EUAE that covers everything and works well, at least on fast computers.

@LiveForIt

Maybe taking the chipset emulation from a recent version of FSUAE and wrapping its GPL2 licensed code in an LGPL3 licensed library framework would insulate calling chipset emulation from the dreaded GPL license bleed-through. Of course that would mean writing a setter for every writable register and a getter for every readable register so the globals never touch non-LGPL code but it would be less patchwork. Chipset.library would be a good name for it.

@thread
If there aren't enough language lawyers trying to upgrade Amiga programming languages to portable code generation, maybe I should consider doing something else.