@OneTimer1

Quote:

OneTimer1 wrote: @fishy_fis Quote: ... Intergrated Petunia/Trance Style 68k CPU Emu In AROS ... Michal Schulz started to develop AROS on ARM BE (big endian) and then he was carried away developing a transparent 68k emulator for this system, it should have worked like the 68k emulation in AOS4 or MOS, but ended as 68k emulator in PiStorm. I don't know if it's still big endian.

Emu68 is still big endian.

Unlike Mac-inspired AOS4's 68K userland-only emulator, Emu68 survives the "kick-the-OS" Amiga games.

The Amiga is not the Mac.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

Correct. It's Intel's Bi-Endian compiler: https://www.intel.com/content/www/us/en/developer/tools/biendian-c-compiler/overview.html

That's the one, thanks. BEC. Could never remember it. Looks a bit old now. Seems it's had it's use. Would be good for the opposite as well. A "LIC" Little Endian Compiler for compiling LE code to BE targets.

Quote:

BSWAP is Stone Age: MOVBE is the way to go in this case.

I agree with that. It is good to have both, as for example PPC can suffer, since it cannot byte swap in register without jumping through hoops. Now, the operation should be at memory level, but using compiler macros it tends to happen at variable level.

Quote:

Another GCC extension...

The above being an example of one that works well on x86 but not on PPC. Despite the PPC able to reverse load and store. The macros don't help at the point where the issue lies.

Quote:

Anyway, this way you need to change all relevant parts in the source code to add this new storage attribute: it doesn't work, because there's too much work.

You do but it's surely less work than trying to find where in code it has dependencies. Code doing advanced checksums can be hard to track. As well as code that assumes or does tricks like cast pointers as word or byte. Some optimise for LE.

Quote:

Ideally you should take Amiga sources as they are and compile them for x86/x64 in a way where the compiler by default assumes big endian for all data accesses and generates the proper MOVBE instructions. But this requires time as well (e.g.: patch GCC or LLVM).

That's pretty much what I'm suggesting. I imagine the Intel BEC would be optimised to do this but I don't know how it works. It would likely emit slower code than would naturally be produced, such as with all scalar read and writes restricted to MOVEBE and in extreme cases pointers. So it would be RISC like, since most read/writes would need to be isolated to MOVBE load/stores. But, it still would be proper code and even on bargain basement x64 CPU, likely faster than an X5000 by a significant amount.

While on the subject I recall a post you made about optimising code or structuring it so the compiler knew what the coder is intending to do. The classic example being a byte swap. You linked to some discussion, but to me it was unclear after reading it, as all the examples people gave relied on the intrinsics of the compiler they used. So it wasn't a reliable way of using generic tokens in code in a specific way that would produce the desired result.

It in fact looked like a "Doing X to produce Y" type problem. Where people have various ways of writing X to produce Y. When it fact it just became obvious, at least to me, that the best way would be to tell the compiler exactly that Y was needed and not beat around the bush with an X. Or beat around the byte in this case. A related problem may be rotation, where CPU's do it natively, but C stopped at the shift even though it was common and easy in ASM.

@Kronos

Quote:

At the very least you would need some basic API to "call out", similar to what Amithlon did. Mind you x86 was still single core 32Bit at that time, but no reason why a similar method couldn't be used on 64Bit multicore HW.

Amithlon ran in a kind of VM. I call it an AmigaOS emulator. It internally did the byte swaps. If it wasn't already famous. Amithlon put BSWAP on the map.

But the extra feature it had, which isn't clear if you are alluding to it, is the native "x86" apps. Where Amiga apps could be compiled as x86 and the OS calls transparently hooked back into 68K emulation. Now, as I understand it, the x86 compiler worked similar to the Intel BIC and all scala operations to memory were byte swapped to be in big endian order.

Not exactly a secret and the killer feature above the JIT. But people wanted OS4 dropped when they found this out. Don't bother porting AmigaOS native to another CPU their idea was, keep the ROM as 68K, and just compile all the support apps as x86.

@Hammer

Quote:

Unlike Mac-inspired AOS4's 68K userland-only emulator, Emu68 survives the "kick-the-OS" Amiga games.

Mac-inspired? How so? I've never seen a screen pop up and boot OS3 when I load a 68K program that then opens up and looks old.

Or do you mean the way way real games don't survive kicking out the OS on OS4 and crash it?

Well, the emulator can still work as it should just like Emu68K, but OS4 underneath would throw a hissy fit if it doesn't have a seizure.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Correct. It's Intel's Bi-Endian compiler: https://www.intel.com/content/www/us/en/developer/tools/biendian-c-compiler/overview.html That's the one, thanks. BEC. Could never remember it. Looks a bit old now. Seems it's had it's use.

Well, I can't tell the numbers, but I can tell you that it generated A LOT of revenues.

BTW, it was developed by my big boss at the time (the site manager), and he was proud (with good reasons) of it. Actually Intel acquired his company many years ago because of this compiler.
Quote:

Would be good for the opposite as well. A "LIC" Little Endian Compiler for compiling LE code to BE targets.

It's Bi-Endian for good reasons...
Quote:

Quote: Another GCC extension... The above being an example of one that works well on x86 but not on PPC. Despite the PPC able to reverse load and store. The macros don't help at the point where the issue lies.

I don't like and I don't support the Embrace, Extend, Extinguish strategy (SIC!) of FSF with its GNU tools. They have poisoned the market with so many extensions which have basically put off many other competitors (the small ones which can't have many developers keeping up).

Even CLang/LLVM had hard time to be able to reach a point where it was possible to compile Linux, and only because this idiocy of custom extensions used "thanks" to GCC & co..
Quote:

Quote: Anyway, this way you need to change all relevant parts in the source code to add this new storage attribute: it doesn't work, because there's too much work. You do but it's surely less work than trying to find where in code it has dependencies. Code doing advanced checksums can be hard to track. As well as code that assumes or does tricks like cast pointers as word or byte. Some optimise for LE.

The problem is that you need to change all sources: AROS and the applications that you want to compile in BE mode.

That's why for me it's a no-go: too much work...
Quote:

Quote: Ideally you should take Amiga sources as they are and compile them for x86/x64 in a way where the compiler by default assumes big endian for all data accesses and generates the proper MOVBE instructions. But this requires time as well (e.g.: patch GCC or LLVM). That's pretty much what I'm suggesting. I imagine the Intel BEC would be optimised to do this but I don't know how it works. It would likely emit slower code than would naturally be produced, such as with all scalar read and writes restricted to MOVEBE and in extreme cases pointers. So it would be RISC like, since most read/writes would need to be isolated to MOVBE load/stores. But, it still would be proper code and even on bargain basement x64 CPU, likely faster than an X5000 by a significant amount.

Yes, more or less. You can't take big advantage of mem-reg / reg-mem x86/x64 instructions, but at least you can make use of its addressing modes.
Quote:

While on the subject I recall a post you made about optimising code or structuring it so the compiler knew what the coder is intending to do. The classic example being a byte swap. You linked to some discussion, but to me it was unclear after reading it, as all the examples people gave relied on the intrinsics of the compiler they used. So it wasn't a reliable way of using generic tokens in code in a specific way that would produce the desired result. It in fact looked like a "Doing X to produce Y" type problem. Where people have various ways of writing X to produce Y. When it fact it just became obvious, at least to me, that the best way would be to tell the compiler exactly that Y was needed and not beat around the bush with an X. Or beat around the byte in this case.

Yes, that's the problem: in theory you don't need intrinsics to generate proper instructions, like BSWAP or MOVBE. It should be enough to write the operations (via macros, for example) and let the compiler identify the pattern for endian swapping, generating the proper instruction.

However compilers can fail because they aren't able to recognize the pattern because it isn't written as they expected.
Quote:

A related problem may be rotation, where CPU's do it natively, but C stopped at the shift even though it was common and easy in ASM.

Exactly. Another used case.

Compilers are evolving catching more patterns, but... it requires time & expertise from developers.

@Hypex

Quote:

Hypex wrote: @Kronos Quote: At the very least you would need some basic API to "call out", similar to what Amithlon did. Mind you x86 was still single core 32Bit at that time, but no reason why a similar method couldn't be used on 64Bit multicore HW. Amithlon ran in a kind of VM. I call it an AmigaOS emulator. It internally did the byte swaps. If it wasn't already famous. Amithlon put BSWAP on the map. But the extra feature it had, which isn't clear if you are alluding to it, is the native "x86" apps. Where Amiga apps could be compiled as x86 and the OS calls transparently hooked back into 68K emulation. Now, as I understand it, the x86 compiler worked similar to the Intel BIC and all scala operations to memory were byte swapped to be in big endian order.

I don't think that there's a special x86 compiler for that.

IMO x86 code should be compiled being aware the some data (e.g. Amiga data structure) are coming from a big endian world.

With all endianess conversion done internally by the JIT (so, only with 68k code).

@Hypex

Quote:

Mac-inspired? How so?

Mac's userland 68K-to-PPC translation approach is not compatible with "kick the OS" games.

The CPU translation approach would be at the Transmeta's or Project Denver's level.

Apple's 3rd party software is not allowed to "kick the OS" and Apple can sell 68LC040/68040/PowerPC Macs in their millions of units.

With Windows NT-based OS domination on desktop PCs, the Windows 11 ARM edition can afford userland X86-64 translation.

Quote:

Or do you mean the way way real games don't survive kicking out the OS on OS4 and crash i

Mac's userland 68K-to-PPC translation approach is not compatible with "kick the OS" games.

With WinUAE's A4000/CyberStormPPC/AmigaOS4.1 FE/AGA display, I ran the Metro Siege hard disk version which resulted in a black screen and corrupt sound.

PiStorm-Emu68-RPi3A+ on A500 full ECS/AmigaOS 3.9 (CaffeineOS) runs Metro Siege hard disk version "out of the box".

Last edited by Hammer on 16-Jul-2024 at 05:24 AM.
Last edited by Hammer on 16-Jul-2024 at 05:21 AM.
Last edited by Hammer on 16-Jul-2024 at 05:14 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hypex

Quote:

Hypex wrote: Amithlon ran in a kind of VM. I call it an AmigaOS emulator. It internally did the byte swaps. If it wasn't already famous. Amithlon put BSWAP on the map. But the extra feature it had, which isn't clear if you are alluding to it, is the native "x86" apps. Where Amiga apps could be compiled as x86 and the OS calls transparently hooked back into 68K emulation. Now, as I understand it, the x86 compiler worked similar to the Intel BIC and all scala operations to memory were byte swapped to be in big endian order. Not exactly a secret and the killer feature above the JIT. But people wanted OS4 dropped when they found this out. Don't bother porting AmigaOS native to another CPU their idea was, keep the ROM as 68K, and just compile all the support apps as x86.

Amiga's 3rd party video NLE software needs a Zorro II/III boat anchor to work. PowerAmiga NG and Amithlon X86 camps have effectively knocked out an entire class of professional Amiga software that was successful in a professional market niche.

ToasterFlyer NLE and MovieShop NLE weren't modified for PowerAmiga NG and Amithlon.
PowerAmiga NG and Amithlon missed the social media video NLE wave.

Amithlon can run Shapeshifter's Adobe Premiere 4.2 NLE for Mac68K which is a Mac platform.

AROS X86 has "just compile the 3rd party apps for x86".

Last edited by Hammer on 16-Jul-2024 at 01:30 PM.
Last edited by Hammer on 16-Jul-2024 at 05:00 AM.
Last edited by Hammer on 16-Jul-2024 at 04:57 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro

Quote:

Well, I can't tell the numbers, but I can tell you that it generated A LOT of revenues. BTW, it was developed by my big boss at the time (the site manager), and he was proud (with good reasons) of it. Actually Intel acquired his company many years ago because of this compiler.

I can imagine. They must have been impressed, Then slapped their name on it.

Quote:

It's Bi-Endian for good reasons...

So could it have been ported to PPC for compiling LE dependent code for PPC BE?

Quote:

Even CLang/LLVM had hard time to be able to reach a point where it was possible to compile Linux, and only because this idiocy of custom extensions used "thanks" to GCC & co..

I expected Linux to be more portable given its nature is to be portable to many hardware systems. And not reliant on one compiler. Even if was common to use it.

Sometimes they are needed, such as when specifying interrupts in Amiga code, which needs a specific attribute. But one that tends to have a generic define that isn't compiler dependant. Such as with SDA includes.

Quote:

The problem is that you need to change all sources: AROS and the applications that you want to compile in BE mode.

That's true. It would need a new branch. But this needs to happen anyway for most new builds. But, for AROS, it's still currently stuck in the ABIv0 vs ABIv1.

AROS was like ColdFire 68K, just source compatible. This could be like a PPC or 68K branch. A low tier branch. Good for proof of concept.

Quote:

Yes, more or less. You can't take big advantage of mem-reg / reg-mem x86/x64 instructions, but at least you can make use of its addressing modes.

I was thinking there is at least that.

Quote:

However compilers can fail because they aren't able to recognize the pattern because it isn't written as they expected.

That's one problem. Perhaps compilers need some buzzword AI in the optimiser to detect it. It's also the code. If the code reads it in then converts it the compiler is forced to reverse it after, unless it widens the view of a code block to see what i going on overall. The code also needs to swap at R/W level which makes it harder to detect. Unless it reads in bytes then reverses. A classic example could be an "ELF" loader looking for a magic ID. Portable code splits it into 4 byte checks. Non-portable can check it for an "FLE" on LE. What I have done is use a "MAKE_ID" macro like for IFF that creates a an ID from shifting around 4 bytes, which doesn't require compiler tricks to detect and optimise byte swap, but has the compiler simply convert it at code level.

But, even with a pattern, it still means that natural code needs to be modified. So if reading from a struct it needs to pass through a macro. I've read up on people solving it with a C++ class which looks like a cleaner approach than C, if it can be a hidden operation.

Quote:

Compilers are evolving catching more patterns, but... it requires time & expertise from developers.

There's just not enough punctuation characters for all these specific operations.

Quote:

I don't think that there's a special x86 compiler for that.

I found it. I was referring to this. Though I haven't tested it to see what it exactly produces.

http://aminet.net/package/dev/gcc/x86-ami-bin

Quote:

IMO x86 code should be compiled being aware the some data (e.g. Amiga data structure) are coming from a big endian world.

Packing structures as word alignment is one step. But how else would they be aware? I mean most if not all Amiga data structures are big endian.

Quote:

With all endianess conversion done internally by the JIT (so, only with 68k code).

Which is how Amithlon ran 68K fast.

@Hammer

I wasn't aware of any Mac games kicking out the OS.

Looks like OS4 continues the tradition of each new OS release being more incompatible with games than the last. Though at first most of those were floppy games so didn't use much of the OS. Given the hardware is compatible I don't know what changes they made to prevent it working on native hardware.

Right now my PiStorm with basic OS3.9 setup is incompatible with almost all games. Or WHDLoad games anyway. I thought OS might be interfering so ran a game from boot shell and it still crashes.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Well, I can't tell the numbers, but I can tell you that it generated A LOT of revenues. BTW, it was developed by my big boss at the time (the site manager), and he was proud (with good reasons) of it. Actually Intel acquired his company many years ago because of this compiler. I can imagine. They must have been impressed, Then slapped their name on it.

Nah. It was greatly extended / updated.
Quote:

Quote: It's Bi-Endian for good reasons... So could it have been ported to PPC for compiling LE dependent code for PPC BE?

I don't recall if other architectures were supported. But I bet that no new ones were added to the existing compiler, for obvious reasons.
Quote:

Quote: Even CLang/LLVM had hard time to be able to reach a point where it was possible to compile Linux, and only because this idiocy of custom extensions used "thanks" to GCC & co.. I expected Linux to be more portable given its nature is to be portable to many hardware systems. And not reliant on one compiler. Even if was common to use it.

Its portability is completely linked to the GCC ecosystem. "Embrace, Extend, Extinguish"...
Quote:

Sometimes they are needed, such as when specifying interrupts in Amiga code, which needs a specific attribute. But one that tends to have a generic define that isn't compiler dependant. Such as with SDA includes.

Some #pragmas might be acceptable only located on very limited and special areas, like the interrupts that you've said.

Everything else... no! Standards are there and are important for very good reasons, which the FSF blind zealots completely ignored with their expensions.
Quote:

Quote: The problem is that you need to change all sources: AROS and the applications that you want to compile in BE mode. That's true. It would need a new branch. But this needs to happen anyway for most new builds. But, for AROS, it's still currently stuck in the ABIv0 vs ABIv1.

Whatever: it's not the way to go. Too much work, also for the existing applications.
Quote:

AROS was like ColdFire 68K, just source compatible.

No, AROS is binary-compatible for the 68k branch.
Quote:

This could be like a PPC or 68K branch. A low tier branch. Good for proof of concept.

It can become the master branch, if the majority of people use it.
Quote:

Quote: However compilers can fail because they aren't able to recognize the pattern because it isn't written as they expected. That's one problem. Perhaps compilers need some buzzword AI in the optimiser to detect it. It's also the code. If the code reads it in then converts it the compiler is forced to reverse it after, unless it widens the view of a code block to see what i going on overall. The code also needs to swap at R/W level which makes it harder to detect. Unless it reads in bytes then reverses.

Yes, AI here might help identify the different patterns and helping compilers to generate the proper instructions.
Quote:

A classic example could be an "ELF" loader looking for a magic ID. Portable code splits it into 4 byte checks. Non-portable can check it for an "FLE" on LE. What I have done is use a "MAKE_ID" macro like for IFF that creates a an ID from shifting around 4 bytes, which doesn't require compiler tricks to detect and optimise byte swap, but has the compiler simply convert it at code level.

Exactly!
Quote:

But, even with a pattern, it still means that natural code needs to be modified. So if reading from a struct it needs to pass through a macro. I've read up on people solving it with a C++ class which looks like a cleaner approach than C, if it can be a hidden operation.

Hum. No, things like IFF chunk IDs SHOULD have been done that way in principle.
Quote:

Quote: I don't think that there's a special x86 compiler for that. I found it. I was referring to this. Though I haven't tested it to see what it exactly produces. http://aminet.net/package/dev/gcc/x86-ami-bin

It's not clear what they are doing. Any better documentation?
Quote:

Quote: IMO x86 code should be compiled being aware the some data (e.g. Amiga data structure) are coming from a big endian world. Packing structures as word alignment is one step.

Packing is the minor thing.
Quote:

But how else would they be aware? I mean most if not all Amiga data structures are big endian.

Which is good: we know it by definition.

However, code which isn't properly for the Amiga o.s. should be compiled natively (and with proper code to make the endian conversions).

One solution I was thinking about is splitting the code in two big branches: one for AROS & Amiga applications, and another one for native drivers & applications. Those are compiled differently. And "glue" code generated when they need to interact each other.

Just a rough idea.
Quote:

Quote: With all endianess conversion done internally by the JIT (so, only with 68k code). Which is how Amithlon ran 68K fast.

Yup. But regarding the emulation, more optimizations might be possible.

And, BTW, Amithlon lacks the MOVBE instruction.

@Hypex

Quote:

Hypex wrote: @Hammer I wasn't aware of any Mac games kicking out the OS. Looks like OS4 continues the tradition of each new OS release being more incompatible with games than the last. Though at first most of those were floppy games so didn't use much of the OS. Given the hardware is compatible I don't know what changes they made to prevent it working on native hardware. Right now my PiStorm with basic OS3.9 setup is incompatible with almost all games.

Name some game examples.

What's your PiStorm setup?

Quote:

Or WHDLoad games anyway. I thought OS might be interfering so ran a game from boot shell and it still crashes.

My two CaffeineOS (AmigaOS 3.9)/PiStorm/Emu68 setups are compatible with most of my tested WHDLoad games.

CaffeineOS is pre-configured to switch into "turtle mode" with WHDLoad games and exit from "turtle mode" after exiting from the game.

I have downloaded most of the parallax effects-enabled WHDLoad games in a game folder for the test.

Last edited by Hammer on 21-Jul-2024 at 11:07 AM.
Last edited by Hammer on 21-Jul-2024 at 11:04 AM.
Last edited by Hammer on 21-Jul-2024 at 10:58 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Amiga's 3rd party video NLE software needs a Zorro II/III boat anchor to work. PowerAmiga NG and Amithlon X86 camps have effectively knocked out an entire class of professional Amiga software that was successful in a professional market niche.

I had some limited success on OS4. Possibly Lightwave or something which I though had been made freeware but now can't find any info about it. In any case Amithlon was made for the user and not the pro as I understood it. But on current hardware it ran like a pros Amiga. By that point however most Amiga pro software had been moved to Mac or PC.

Quote:

ToasterFlyer NLE and MovieShop NLE weren't modified for PowerAmiga NG and Amithlon. PowerAmiga NG and Amithlon missed the social media video NLE wave.

It must have been dependant on the hardware even though they need to run on the OS.

Quote:

Amithlon can run Shapeshifter's Adobe Premiere 4.2 NLE for Mac68K which is a Mac platform.

That sounds more ancient than Amiga 68K which lasted longer on 68K.

@Hammer

Quote:

Hammer wrote: Amiga's 3rd party video NLE software needs a Zorro II/III boat anchor to work. PowerAmiga NG and Amithlon X86 camps have effectively knocked out an entire class of professional Amiga software that was successful in a professional market niche.

As always you get the facts kinda right only to then go of rail.

By the time Amithlon and NG came around every NLE video HW for Amiga was obsolete with vendors either having move elsewhere (PC,Mac custom HW) or nowhere.

If anything they failed to on with the program, which they could have done as everything was still based around PCI cards and single core CPU at that time.

There was MotionStudio planned for MorphOS but like so many things promised back than it never materialized.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@cdimauro

Quote:

Nah. It was greatly extended / updated.

It was quite useful then.

Quote:

Its portability is completely linked to the GCC ecosystem. "Embrace, Extend, Extinguish"...

Then there's no excuse for Linux and drivers not be totally portable to any endian. They can expand on their __be16/32/64 typdefs to specify scalar order in GCC. Awkward be16_to_cpu macros no one uses will be obsolete!

Quote:

Everything else... no! Standards are there and are important for very good reasons, which the FSF blind zealots completely ignored with their expensions.

Things like interrupts and ABI particulars are sensitive and need to be exact on Amiga. But so would it need to be on other platforms.

Quote:

No, AROS is binary-compatible for the 68k branch.

That looks like a late inclusion. Since point of AROS was portability away from ageist 68K. I tend to think it's strange there is AROS for 68K as 68K has the original AmigaOS still in development. And even if not it has the real thing. I'm probably picky, as I see it as novel, but on an Amiga I'd want to run the real AmigaOS and not a cover version.

Quote:

Yes, AI here might help identify the different patterns and helping compilers to generate the proper instructions.

It does need some intelligence above normal optimising to detect the operation from smaller blocks and see what end result is, so it can squeeze it back down again, hopefully into one instruction.

Quote:

Whatever: it's not the way to go. Too much work, also for the existing applications.

I bet it would be more popular than AROS PPC. Which is mostly a novelty I think. At least for Sam hardware.

Quote:

It's not clear what they are doing. Any better documentation?

I can't find any online. There's a news report. And a blog. If you read what you can find it's some kind of cross compiler that does produce some kind x86 binaries. ISTR it's built on UAE backdoor hooks, or the same kind of mechanism, that allows 68K to hook into host via custom 68k traps. It's called i686be so it's some kind of big endian compiler for x86. A precursor to Intel BEC perhaps, though I don't what exited first.

https://anna.amigazeux.org/comments2.php?view=1027605442&category=files&start=1

https://amithlonblog.snkbitten.com/i686be-amithlon-ahidev-audio-working/

Quote:

Packing is the minor thing.

It can be major on the Amiga as objects have word alignment. So for a CPU like PPC, it likes long word alignment. Without packing this would break a few libraries.

Quote:

One solution I was thinking about is splitting the code in two big branches: one for AROS & Amiga applications, and another one for native drivers & applications. Those are compiled differently. And "glue" code generated when they need to interact each other.

Yes I can see, how applications are usually portable, but Amiga drivers are more low level to hardware.

Quote:

And, BTW, Amithlon lacks the MOVBE instruction.

It does because its old. But it's only one less instruction. Or, it can replace the previous MOV and BSWAP with one MOVBE.

I wonder why the idea hasn't been reimplemented? Reasons I've heard is licensing issues and getting sued. Sued, by who, H&P? UNIX was reimplemented as Linux, that survived, to the point of taking over future markets. AmigaOS is reimplemented as AROS, and in a similar way, also taking over the real thing now in places. If we think of Amithlon as a standard, or just as an idea, since UAE has the JIT included now, what's stopping a keen developer from stripping down a Linux kernel and customising UAE on top? Even without i686be reimplemented as x86be or x64be I don't see why it wouldn't be possible.

@Hammer

Quote:

Name some game examples.

AlienBreed3D2. Wander3D. Tornado.

All are WHDLoad games.

Quote:

What's your PiStorm setup?

PiStorm32-lite mated to RPi 3A+. 16GB SD card. OS3.9 Workbench and Work volumes formatted as SFS.

Quote:

My two CaffeineOS (AmigaOS 3.9)/PiStorm/Emu68 setups are compatible with most of my tested WHDLoad games.

I've never been able to get any working. They just crash and reboot. I can boot Elfmania demo off CU floppy and it works fine.

I'm suspecting my setup. I spent some time creating a basic boot floppy. Tested it with loading AB3D and it still crashed.

There is some corruption going in. I load programs into MonAM and even some small code takes a while to load up and the 68K is gibberish! It's as it's affected by a classic max transfer setting or bad ram. But the OS can boot and run. So no idea!

Quote:

CaffeineOS is pre-configured to switch into "turtle mode" with WHDLoad games and exit from "turtle mode" after exiting from the game.

So it uses OS3.9. I've been wanting to install OS3.9 fresh but do we need to disable the ROM Update? I can find no where that states if that needs to be turned off or can be left on with PiStorm. I don't know how this isn't listed anywhere. Along with max transfer. These are major blockers for hardware configurations known to cause faults and no one mentions them!?

Quote:

I have downloaded most of the parallax effects-enabled WHDLoad games in a game folder for the test.

Do the games instantly crash without "turtle mode" when loaded?

@Hypex

Quote:

Hypex wrote: I wonder why the idea hasn't been reimplemented?

Amithlon had 2 key advantages.

1. it was much faster then WinUAE on the same HW
-- WinUAE has progressed quite a lot the past 20 years making that harder to achieve
-- PC HW has gotten so much faster that there isn't much of a need for it

2. Out of the box integration of AmigaOS3.9.
-- doubtful you could license anything better than 3.1 for it (and even 3.1 would be kinda iffy)

EMU68k is the closest in technical terms and if someone what it could be made to run on ARM ATX motherboard or Snapdragon laptop accessing the directly via PCI.
Basically a NG system somewhere between Amithlon and the Draco, I just don't see enough demand/interest for such a thing to make it viable.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Everything else... no! Standards are there and are important for very good reasons, which the FSF blind zealots completely ignored with their expensions. Things like interrupts and ABI particulars are sensitive and need to be exact on Amiga. But so would it need to be on other platforms.

np: #pragmas are there for this. But definitely NOT the custom language extensions.
Quote:

Quote: No, AROS is binary-compatible for the 68k branch. That looks like a late inclusion. Since point of AROS was portability away from ageist 68K.

No, AROS' goal was to be Amiga o.s. source-compatible for all platforms and binary compatible with the original / 68k one, and that was defined since day one.
Quote:

I tend to think it's strange there is AROS for 68K as 68K has the original AmigaOS still in development. And even if not it has the real thing. I'm probably picky, as I see it as novel, but on an Amiga I'd want to run the real AmigaOS and not a cover version.

The problem is that after Commodore bankrupt then there was no Amiga o.s. development, and AROS was born to give it a future, whatever could have happened to the companies which owned the brand.
Quote:

Quote: It's not clear what they are doing. Any better documentation? I can't find any online. There's a news report. And a blog. If you read what you can find it's some kind of cross compiler that does produce some kind x86 binaries. ISTR it's built on UAE backdoor hooks, or the same kind of mechanism, that allows 68K to hook into host via custom 68k traps. It's called i686be so it's some kind of big endian compiler for x86. A precursor to Intel BEC perhaps, though I don't what exited first. https://anna.amigazeux.org/comments2.php?view=1027605442&category=files&start=1 https://amithlonblog.snkbitten.com/i686be-amithlon-ahidev-audio-working/

It looks like another cross-compiler. There's nothing interesting, besides that it generated code for Amithlon's platform/ABI.
Quote:

Quote: Packing is the minor thing. It can be major on the Amiga as objects have word alignment.

Only on the 68000. I prefer to think about something newer, eh!
Quote:

So for a CPU like PPC, it likes long word alignment. Without packing this would break a few libraries.

No misaligned load/store instructions on PowerPCs?!?
Quote:

Quote: One solution I was thinking about is splitting the code in two big branches: one for AROS & Amiga applications, and another one for native drivers & applications. Those are compiled differently. And "glue" code generated when they need to interact each other. Yes I can see, how applications are usually portable, but Amiga drivers are more low level to hardware.

Even Emu68 has drivers written in 68k code.

What I proposed is different: as much as code possible should be native (e.g.: second branch) to take fully advantage of the host platform. The rest (AROS, mainly) is compiled as big-endian to make 68k applications first-class as AROS.
Quote:

Quote: And, BTW, Amithlon lacks the MOVBE instruction. It does because its old. But it's only one less instruction. Or, it can replace the previous MOV and BSWAP with one MOVBE.

That's the point, since MOVBE is much faster (and more instructions like that can be executed per clock cycle).
Quote:

I wonder why the idea hasn't been reimplemented? Reasons I've heard is licensing issues and getting sued. Sued, by who, H&P? UNIX was reimplemented as Linux, that survived, to the point of taking over future markets. AmigaOS is reimplemented as AROS, and in a similar way, also taking over the real thing now in places. If we think of Amithlon as a standard, or just as an idea, since UAE has the JIT included now, what's stopping a keen developer from stripping down a Linux kernel and customising UAE on top? Even without i686be reimplemented as x86be or x64be I don't see why it wouldn't be possible.

It's possible, but I agree with Kronos here.

I've a different idea about that, since many years: I prefer to have an Amiga "virtualizer" which allows the transparent execution of Amiga applications on the host system, including a JIT.
Imagine clicking on an Amiga icon file and it launches the given application which opens its window like any native application of your system.

@Kronos

PC hardware is faster. And also, people like to run a VM thesse days, over needing to reboot into another OS. I can see that. To play some games I need to reboot into Windows. I'd use VBox or similar if I could and avoid that. But direct partitions aren't supported. However, for Amithlon, a VM would be a good way to run it at full speed as well and especially to avoid hardware incompatibility.

Supposes including OS3.9 was useful. But it's not too hard to supply your own. Just hook in an OS3.9 CD and boot. Or OS3.2 these days. And any other combo based on OS3.1 and up. Plus the ROMs which most people would have.

@Hypex

https://docs.google.com/spreadsheets/d/1Y-2eRNB6LaLTRhYJo_Wxsp3AUeZmWp-0QBYirMoHkc8/edit?usp=sharing

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC