@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.

@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.

@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.

@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.

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?

@MigthyMax

The point I was trying to make was that Rust is a fast-moving target and won't stay up-to-date very long.

@MigthyMax
It looks like your Reddit link is about right. It's also about 5 years old.

Re:Rust
I have been using Rust on Haiku for a while now and the syntax highlights are all the editors there have to offer. Tier 3 support means no cross compiler hosting for other platforms to use. The source is hosted on GitHub like any other source and the build recipe on HaikuPorts builds a native Haiku compiler for the HaikuDepot package manager using Haiku's own continuous integration expenses. Fortunately, Haiku Inc. is a non-profit corporation so the CI build bots are probably donated.

If the same thing were done for AmigaOS 4.1fe2, who would maintain the build bots and at whose expense? Neither AEon nor Hyperion are non-profit groups.

I always hoped that someone could write a custom pass manager that would allow each pass of the optimizer to be stored in a separate shared library so they could load in a few at a time and close the unused ones so they could be flushed out of RAM on an Amiga.

I was naieve enough at one point to think that someone would be me. Heh! Weren't those the days!

Although I'm going the other direction, from Amiga to Haiku, I'm glad you've come to terms with being an Amigan. My MicroA1 is bordering on unusable with the latest version of AmigaOS 4.1 and it's hard to get excited about a 15 year old Mac Mini running MorphOS, but I find scripting in Hollywood tolerable in MorphOS and Linux.

I was hoping to get a cut down version of the PicoEVB for my PineBook Pro and run it under Linux with a MiniMig core variant with the video and audio rendered as memory-mapped I/O to the host hardware. Of course the DevBoard I've linked is way more complicated than it needs to be and it costs $200+ to reflect that. The rest of the chipset emulation can run on one of the little cores on the RockChip RK3399 while one of the big cores can run the actual JIT code.

This chip would be well suited to running on a PCI or PCIe board also. It runs fanless and has enough space for future expansions such as SAGA chipset emulation like the Vampire standalone. I'm not sure how much the FPGA chip costs by itself though.

I heard on Amiga Addict magazine's Discord server that AmigaKit is voicing objections to the Amiga Addict trademark application. Others have voiced instances where AmigaKit had beaten A1200.net to the trademark office and misrepresented their A1200 cases as their own product. Anither lawsuit is brewing there too.

Where will this all end?

I suggested using an augmented MiniMig core as an alternative to modern graphics drivers. It was a possibility that couldn't be made modern because of massive incompatibility between floating-point based 3d acceleration and integer-based Amiga chipset modes.

On another occasion I tried to create a translation layer that would use shaders on modern graphics chips to implement copper-style tricks. It could emulate a palette with copper shading in theory but nothing more. Most modern chipsets aren't designed for palette modes anyway.

Perhaps a hybrid solution could exist: a Minimig core that could output to a texture map so a modern card could display the emulation in a window.

Since all the named labels are behind a string hash lookup to translate to the numbers, your example might already work. Computed Goto and Gosub commands might take some more doing because they are numbered but nothing a second hash can't provide. The functions-in-the-data-statements are indeed tricky. I might need to link to a second C++ file to implement that coroutine. This is my second attempt at compiling AmosPro as portable code. The first failed attempt was codenamed Mattathias.

@LiveForIt

To describe the compilation strategy see this Yab2Cpp wiki entry.

@Kamelito

YAB stands for "Yet Another BASIC". It is the BASIC interpreter used by the Haiku operating system as a hand-me-down from the later days of BeOS. It's fully open-source and exists for making GUI based applications much easier to write.

@LiveForIt

It uses the same algorithm as Mequa was going to use on XAmos before he died. I plan on making it work with AmiDark's AmosPro Unity libraries sometime after Yab but would like to share some code with your Amos Kittens project as well on AmigaOS 4 if you are willing.

In the meantime I'll be focusing on making Yab compile using C++11 as a backend. Maybe if I can find some help I might get an Amiga Yab working as well. (The interpreter is partially translated to Windows, Mac and Linux using FLTK as an API.)

@Capehill

Thanks for looking into it. Not having to backport completely down to C99 helps a lot.

I'm writing a BASIC to C++ exporter/transpiler in C++11. I need to know if I can use it on AmigaOS after I'm done with the Haiku native version: It's called Yab2Cpp.

Thanks Raziel. I would have had to figure out a way to split endians along the lines of a sandbox if I tried to do it on AmigaOS 4.1FE anyway.

GCC 10 and LibStdC++ can do it if it's up to date. The LLVM equivalent to LibStdC++ is LibC++ and it's as much of a pain to port as LibStdC++.

Rust uses LLVM as a backend and optimizer. It doesn't specifically use GLibC unless you are using the Linux backend. It does need to be able to compile LLVM in C++20 or so.

Hello, I haven't posted here for a while.

I'm kicking around the idea of trying to get Rust to cross compile to OS 4 and then see about getting Wasmer to run on it. One dependency that seems to be hard to avoid is that the WASI ABI for Wasmer uses shared objects in a POSIX-style format. If there is a query capable symbol exporter for an OS 4 shared library, that might be another option.

Another hard-to-avoid dependency is that the Wasmer sandbox environment is strictly little-endian. This means that anything accessible outside of the sandbox will need to be endian swapped to interface to the OS.

That said, I haven't learned to program in Rust yet so don't get your hopes up of having a glut of software written for Wasmer at this time.