Ok, thanks for that but ARM is noted to be bi-endian and is not x86 compatible. Was this not taken into account? ARM is such an easy to land arcitecture with very little in prohibitive investments. 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. 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.
@SHADES There is absolutely nothing novel or unique to ARM being "bi-endian" on 32 bit.
Correction. You said ARM was little endian and he corrected it to bi-endian.
Hyperion-Director Quote:
This was part of PowerPC specification way back in the early '90s.
Little endian support on PPC was optional and inconsistently supported. Some CPUs and boards did not support it, some CPUs only supported unaligned big endian memory accesses in hardware handicapping little endian mode, some embedded CPUs only supported little endian memory accesses on a per page basis using the MMU. Endian mode switching is difficult. PPC has load/store instructions which convert endianess. PPC support for little endian was poor.
ARMv7/AArch32 also has optional endian support but it is more consistent where implemented. It supports endian mode changes on the fly and it has instructions for converting endianess. This was overall good endian support. ARMv8/AArch64 deprecates easy endian mode switching on the fly and practically forces little endian mode as the default endianess. Instructions which convert endianess are encouraged instead of operating in big endian mode or on the fly endian mode changes which some cores may still support. Big endian mode support may become less and less common and may be removed at some point. This big endian support is less impressive and more on par with PPC.
Correct me if wrong michalsc.
Hyperion-Director Quote:
However 32 bit x86 has always been little endian. Even silly "virtual CPU" like TAO's "Elate" (aka AmigaDE) were little endian and suffered a huge performance penalty when being run on a big endian CPU (which is rather idiotic on a virtual CPU if you ask me).
Indeed. It would be nice for performance if a virtual CPU uses the native endianess but that has disadvantages as well.
Hyperion-Director Quote:
This also means that the firmware of many graphics cards require little endian.
Initialization time for gfx cards is generally not important for a desktop (it may be for embedded use). Accessing little endian gfx card registers and buses during use is more important although most 3D gfx data does not need to be handled often by the CPU cores. Static data written to registers can have the endianess converted in the source code by the way. I was surprised to see static numbers in little endian format converted to big endian at run time in the 68k Warp3D driver libraries like the Avenger libraries. Of course the 68k Warp3D libraries were an optimization disaster which included much more than poor endian handling.
Hyperion-Director Quote:
Hyperion has spent many years porting x86 to big endian systems (AmigaOS, MacOS) and one of the hardest and most time consuming parts were often related to endianness.
Yes, you can switch a PowerPC to little endian with many ISA's. But this results in a lot of performance hits running 68K native programs. Many games we ported were hardwired to little endian and rooting out these hardcoded little endian issues was a massive undertaking.
Many programmers don't care about supporting big endian which is becoming more and more common as big endian disappears. Let's take a look at 32 or 64 bit natively (default and best support) big endian ISAs which are in use with hardware designs still available today.
68k & ColdFire - practically dead PPC - practically dead POWER - has better little endian support than big endian now MIPS - transitioning to little endian RISC-V SPARC - esoteric but has newer designs than PPC AVR32 - Atmel switched to ARM and Linux support has been dropped J-Core - Modern open hardware re-implementation of SuperH
Of these, the only ISA likely to be used in enough ASIC cores in quantity to compete with ARM pricing is J-Core. Hitachi created the SuperH ISA after they were licensed to produce the 68000 from Motorola and the ISA resembles the 68k. Hitachi licensed patents to ARM for the Thumb modes. The 68k, SuperH and then ARM Thumb were the ISAs each used in the best selling 32 bit embedded cores in the world.
I talked to Jeff Dionne pointing out some flawed data he used on code density which was one of the most important considerations for the SuperH choice. Instead of SuperH having slightly better code density than the 68k for some code he was using in a presentation, the 68k actually has ~29% better code density and uses ~37% fewer instructions for that code. Jeff is planning to use J-Cores in mass produced embedded IoT for the business he works for in Japan. J-Core is nice for small cores but I doubt the performance will scale up the way he want it to. An interesting thing about the video is how the 68k and Amiga solved so many of the problems he faces for a small footprint embedded system.
The whole topic is rather pointless though. Hyperion wins the court battle and doesn't have enough money to do anything on the dwindling number of big endian choices or Hyperion loses the court battle and it is difficult to imagine them staying in business. Small business is often about finding ethical business partners who can help each other but I'm afraid Hyperion has used up its good will and abused its reputation to the point of no return. What are you hoping to hold out for?
1. Hyperion wins the court battle a) Hyperion can't afford to port AmigaOS to new hardware b) without new affordable hardware AmigaOS revenues will dry up c) game over 2. Hyperion loses the court battle a) Hyperion loses all sources of AmigaOS related revenue b) Hyperion owes more money than they can ever repay c) game over 3. Hyperion sells everything AmigaOS related and/or settles a) Hyperion may receive funds to survive and legal costs are reduced b) Hyperion could then go back to porting games
Last edited by matthey on 18-Apr-2021 at 05:25 AM. Last edited by matthey on 18-Apr-2021 at 05:21 AM. Last edited by matthey on 18-Apr-2021 at 05:20 AM.
I personally just think emulation is the way to go now, maybe make the Os more aware that it being emulated and make it kind of like a virtual Os. Amikit on pi and Windows is great vision of this and what could be done.
look how good WinUAE has become, I still love how AmigaOS works and would love native port of it to other hardware and platform but we have to aware of the limited resource we got as a community, it’s amazing achievement of what has been done. But I’m more a future looking person where do we see Amiga in 10 years time? PPC I just don’t see a future for the platform long term. Where as if you type in any computer / console product you can think off and add the words Uae your find the Amiga emulator has been ported too it. I think it’s a massively under-utilised part of the Amiga market.
Hyperion the self should know this as soon as PPC support came to winuae I’m sure sales went up for the classic os4.
11 crawler(s) on-line.
134 guest(s) on-line.
0 member(s) on-line.
SHADES 
