@DiscreetFX

"Apple got x86 working on ARM chips no problem."

The instruction set in ARM is very different to x86 and Apple uses Rosetta to emulate/interperate missing instructions. It is not without problems or performance hits either.
A lot like UAE for AMIGA in this instance.

Last edited by SHADES on 19-Apr-2021 at 06:13 AM.

_________________
It's not the question that's the problem, it's the problem that's the question.

Quote:

SHADES wrote: My point was that ARM is not designed to be little endian. So, I wanted to know why he stated it was. Also, I wanted to know that if this was the biggest problem, and ARM does not have this requirement, why it was not considered.

ARM was originally designed to support little endian only. It is still what I consider to be natively little endian. Bi-endian ARM cores usually default to little endian mode and executing code may always be little endian. I'm not sure when bi-endian support was added but at least ARMv6 and ARMv7 have good optional support for big endian mode. At one time, the "future" big desktop architectures like PPC, MIPS, SPARC, PA-RISC and ALPHA had better big endian support and embedded had better big endian support with 68k, ColdFire, SuperH and PPC (networking often used big endian buses). Then x86/x86-64 reasserted domination of the desktop and ARM took over the embedded market. Many of the big endian architectures became bi-endian. Bi-endian usually does *not* mean equal hardware support for both and the bias is usually in favor of the native endianess. Development tool support is also usually not equal with native support being better. IBM has devoted huge resources to making little endian support on POWER as good as big endian but there are likely still some things big endian like executing code (mixed endian is ugly). Big endian ARM likely has been considered as an AmigaOS porting target and likely would be an easier target than x86-64 but there are disadvantages also.

SHADES Quote:

Surely the PPC world or x86 is a lot harder to cater for, you just mentioned the boot code for graphics cards etc. A lot of ARM SoC CPU's have a gpu core inbuilt already.

GPUs built into SoCs have hardware registers which may be little endian also. Some buses like PCI use little endian by default. Most GPUs have better little endian support today.

SHADES Quote:

The best thing about them is the platform doesn't change much so there is no need to support a multitude of devices or chipset platforms etc. Pi is a perfect example of this.

ARM up to ARMv7 lacked standardization so ARM hardware was practically all configured different. Even the CPU cores support different modes and extensions. This made it difficult to support a wide range of devices. Android has relatively poor performance, is buggy on some hardware and doesn't support some hardware because of this. ARMv8 became much more standardized which improves performance and portability of code but it looks like one of the standardizations is a move to little endian as the default endianess with endian conversion instructions as the favored way of dealing with big endian data. This is *not* efficient when most of the data is big endian though.

The Raspberry Pi has produced enough hardware to create a pseudo ARM standard but that only applies to RPis. There are still significant differences between versions of the RPi. The first SoC only had an old ARMv6 core while newer cores have higher performance cores and features yet many OS distributions use older and less efficient code which still runs on the early RPis (32 bit ARMv6 instead of 64 bit ARMv8). So far, I believe all RPis support big endian mode but that could change as ARMv8 AArch64 only cores become more popular (AArch32 is a compatibility bridge with older ARM). Certainly, big endian mode is not being used much on RPis. Someone asked about big endian mode on a RPi in the following thread.

https://www.raspberrypi.org/forums/viewtopic.php?t=183735

Many responses were not very helpful to nearly being hostile toward big endian.

Quote:

I really don't understand why anyone would ever use bigendian. It is clearly a violation of the Natural Order Of Things and quite possibly the ill-advised use of it has caused fractures in reality that have left us with the current level of insanity in the political world. Nasty gibbering things from the dungeon dimensions.

Quote:

Irrelevant; ARM provides instructions for all sorts of ways to handle big-endian-evil. For example REV Rd, Rm ARMARM DDI0406Q p. A8-270 REVSH Rd, Rm ibid. pp A8-274-5 REV16 Rd, Rm ibid. pp. A8-272-3 Unless you have some near-magical way to get data in and out so fast that spending an instruction endian-swapping before and after any other manipulation is significant, I don't see much likelihood that you need anything else.

Sadly, the last quote is likely the recommended way to handle big endian data on newer ARMv8 cores and the most future safe. In my opinion, big endian support on ARM is likely to get worse.


DiscreetFX Quote:

Apple got x86 working on ARM chips no problem.

Hyperion couldn't afford to pay 398.960 EUR while Apple is richer than some countries.

Apple's fortune turned around when they entered the embedded market with the iPod and then iPhone. Their desktop market is small in comparison. Using ARM chips for desktop will reduce costs especially now that they are developing their own ARM SoCs.

Last edited by matthey on 19-Apr-2021 at 04:44 AM.

@DiscreetFX

Quote:

DiscreetFX wrote: @SHADES Apple got x86 working on ARM chips no problem.

But Apple is Apple. A switch from one cpu to another is no easy task regarding manpower and money. As Ben said: It's of course possible but not without a certain amount of time and money.

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD