MorphZone

AROS on ARM

Andreas_Wolf

# 1
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

Epilogue: This comment was originally a reply to that comment, but was spun off by the powers that be into its own thread, together with most of its follow-up comments.

> AROS now boots natively on Raspberry PI: [...]

New plans for AROS on Raspberry Pi (emphasis mine):

"I would like to [...] push forward the native AROS version for RaspberryPi. [...] The new raspi port of AROS shall work in BigEndian mode [...]. With gcc compiler which can switch endianess on the fly and with Raspberry's CPU which is able to run in BE mode it should be feasible. [...] Once AROS will reach the state where it can boot on Raspberry in BE mode it will be time to upgrade/complete the drivers. [...] current port is not really complete, e.g. it lacks the USB support completely. [...] Imagine having a source code compatible AROS on a 32-bit big endian machine. [...] Same endianess, 32-bit... Could a seamless integration of m68k be made? I don't know now for sure, but maybe it could... [...] the first step is to bring raspberry in big endian to a state where it is working properly. Here the additional CPU cores will be up, but rather left idling. Now, regarding compatibility [of multicore-supporting AROS] with classic software [...] I came up to a conclusion, that the spinlocks do not *have* to be part of the old structures. They could just be linked to the structures they protect (think about a hash table which returns a spinlock for given message port). Therefore I would like to risk and say - at least to some degree it could be possible, as long as old software behaves nicely."
https://www.patreon.com/posts/i-owe-you-some-20956961

[ Edited by Andreas_Wolf 17.01.2020 - 21:12 ]
»30.08.18 - 17:55

Andreas_Wolf

# 2
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

Update:

> New plans for AROS on Raspberry Pi (emphasis mine): [...]

"I wrote you once that in the future there will be a possibility to use m68k binaries with AROS on RasPi, and I really mean it. [...] So, here it goes, my new project on github - Emu68. The project is in very early stage and there is almost no code inside but hey, it's 4 days old, only. What is Emu68? It is going to be a JIT emulator for 680x0 processors. It is not going to be a pure m68k emulation with all bells and whistles (maybe it will get the completeness later on), only the parts necessary to run the code. [...] During next days I will [...] eventually start some benchmarking."
https://www.patreon.com/posts/dromaiidae-emu-24407987

Repository:
https://github.com/michalsc/Emu68
»02.02.19 - 15:10

Andreas_Wolf

# 3
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

Edit: This comment was originally a reply to that comment, but was spun off by the powers that be into another thread, together with other comments.

Reading Michal's Patreon posts from the last several months, it has become clear that his aim isn't an ARM-native AROS anymore but AROS/m68k running on his Emu68, which in turn is running directly on the ARM CPU without OS underneath.

"My initial idea was to run it as a seamless integration for legacy apps, with rest of the system running as an ARM code. However, limitations on the ARM side required by such approach, e.g. all parameters to system functions, hooks etc. passed through a fake m68k register frame, as well as variety of already available target architectures on AROS lead me to a conclusion, that one could run entire OS in such virtual machine, provided it is fast enough. And since my Emu68 seems to be indeed fast enough, it will run entire AROS, including hardware drivers. This gives us a stable ABI (the one from AmigaOS) and binary compatibility with OS-friendly software."
https://www.patreon.com/posts/emu68-on-aarch64-33084316 (comment)

[ Edited by Andreas_Wolf 17.01.2020 - 21:11 ]
»14.01.20 - 10:54

Jim

# 4
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

Quote:

Andreas_Wolf wrote:
Reading Michal's Patreon posts from the last several months, it has become clear that his aim isn't an ARM-native AROS anymore but AROS/m68k running on his Emu68, which in turn is running directly on the ARM CPU without OS underneath.

"My initial idea was to run it as a seamless integration for legacy apps, with rest of the system running as an ARM code. However, limitations on the ARM side required by such approach, e.g. all parameters to system functions, hooks etc. passed through a fake m68k register frame, as well as variety of already available target architectures on AROS lead me to a conclusion, that one could run entire OS in such virtual machine, provided it is fast enough. And since my Emu68 seems to be indeed fast enough, it will run entire AROS, including hardware drivers. This gives us a stable ABI (the one from AmigaOS) and binary compatibility with OS-friendly software."
https://www.patreon.com/posts/emu68-on-aarch64-33084316 (comment)

Sounds like a remarkably intense downgrade and a waste of resources.
And "ABI"? I assume he meant API.
"Never attribute to malice what can more readily explained by incompetence"
»14.01.20 - 11:07

Kronos

# 5
Moderator

Posts: 2325 from 2003/2/24

ABI makes sense as AROS is always using the Amiga API regardless of the used ABI.
»14.01.20 - 11:22

Jim

# 6
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

Quote:

Kronos wrote:
ABI makes sense as AROS is always using the Amiga API regardless of the used ABI.

Application Binary Interface? OK, I think I can wrap my head around that.

BTW - What does the Pi or AROS have to do (directly) with MorphOS?
"Never attribute to malice what can more readily explained by incompetence"
»14.01.20 - 11:38

terminills

# 7
Butterfly

Posts: 100 from 2012/3/12

Quote:

Jim wrote:
Quote:

Andreas_Wolf wrote:
Reading Michal's Patreon posts from the last several months, it has become clear that his aim isn't an ARM-native AROS anymore but AROS/m68k running on his Emu68, which in turn is running directly on the ARM CPU without OS underneath.

"My initial idea was to run it as a seamless integration for legacy apps, with rest of the system running as an ARM code. However, limitations on the ARM side required by such approach, e.g. all parameters to system functions, hooks etc. passed through a fake m68k register frame, as well as variety of already available target architectures on AROS lead me to a conclusion, that one could run entire OS in such virtual machine, provided it is fast enough. And since my Emu68 seems to be indeed fast enough, it will run entire AROS, including hardware drivers. This gives us a stable ABI (the one from AmigaOS) and binary compatibility with OS-friendly software."
https://www.patreon.com/posts/emu68-on-aarch64-33084316 (comment)

Sounds like a remarkably intense downgrade and a waste of resources.
And "ABI"? I assume he meant API.

Downgrade? I wouldn't say downgrade as it allows a single application binary for MC68k, ARM32 and AAarch64 systems.
»17.01.20 - 11:11

Andreas_Wolf

# 8
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

>>> his aim isn't an ARM-native AROS anymore but AROS/m68k running on his Emu68

>> Sounds like a remarkably intense downgrade

> Downgrade? I wouldn't say downgrade as it allows a single
> application binary for MC68k, ARM32 and AAarch64 systems.

I guess he refers to the performance downgrade of running the entire OS through an m68k JIT compiler compared to the original plan of running the OS natively on ARM, which btw would have offered the single application binary feature as well thanks to the transparently running m68k JIT compiler that was supposed to be integrated into AROS/ARM.
»17.01.20 - 11:34

terminills

# 9
Butterfly

Posts: 100 from 2012/3/12

Quote:

Andreas_Wolf wrote:
>>> his aim isn't an ARM-native AROS anymore but AROS/m68k running on his Emu68

>> Sounds like a remarkably intense downgrade

> Downgrade? I wouldn't say downgrade as it allows a single
> application binary for MC68k, ARM32 and AAarch64 systems.

I guess he refers to the performance downgrade of running the entire OS through an m68k JIT compiler compared to the original plan of running the OS natively on ARM, which btw would have offered the single application binary feature as well thanks to the transparently running m68k JIT compiler that was supposed to be integrated into AROS/ARM.

As I understand from talking to Michal AAarch64 wouldn't allow for the emulator to work that way. So essentially the current design allows the stable ABI across all 3 branches vs only 2. I could be wrong though.
»17.01.20 - 13:50

Andreas_Wolf

# 10
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

> As I understand from talking to Michal AAarch64 wouldn't allow for the emulator
> to work that way.

In this case he could have run the ARMv8/AArch64 CPUs in ARMv7/AArch32 mode, which almost all of them are compatible with.
»17.01.20 - 21:26

terminills

# 11
Butterfly

Posts: 100 from 2012/3/12

Quote:

Andreas_Wolf wrote:
> As I understand from talking to Michal AAarch64 wouldn't allow for the emulator
> to work that way.

In this case he could have run the ARMv8/AArch64 CPUs in ARMv7/AArch32 mode, which almost all of them are compatible with.

True but then his emulator would gain the benefits of the extra registers and ram available to AArch64.
»18.01.20 - 10:03

Andreas_Wolf

# 12
Yokemate of Keyboards

Posts: 12157 from 2003/5/22

From: Germany

> then his emulator would gain the benefits of the extra registers
> and ram available to AArch64.

I can see the point regarding the registers, but can his current solution make use of the extra RAM, considering that emulated m68k is still a 32-bit architecture just like AArch32?
»18.01.20 - 19:30

terminills

# 13
Butterfly

Posts: 100 from 2012/3/12

Quote:

Andreas_Wolf wrote:
> then his emulator would gain the benefits of the extra registers
> and ram available to AArch64.

I can see the point regarding the registers, but can his current solution make use of the extra RAM, considering that emulated m68k is still a 32-bit architecture just like AArch32?

Yes the jit itself can take advantage of it in the form of more cache
»18.01.20 - 20:02