Quote:

BigD wrote: It is pointless FIXING the platform if there's then no compatible software of interest (ala AROS) and people with a PC rig will 99.999999% of the time boot Windows or Linux which DO have applications!

You have a good point. Perhaps more comparable to the AmigaOS is the original ARM RISC OS on the Raspberry Pi. Raspberry Pi sales near 20 million have generated huge traffic of people taking a look but only a few thousand have stayed as users. They do have a descent browser in NetSurf, but the AmigaOS is more modern with more features and has more software, especially games. It certainly is an uphill battle without software.

Much of the Raspberry Pi success is due to software. It was pushing the cost down which made it successful but it is software and standardization/compatibility which is sustaining it. There is similar ARM hardware which is faster and lower power at the same price. For example the Libre Renegade board ROC-RK3328-CC SBC is $35 with 1 GiB of ram.

https://www.loverpi.com/collections/renegade/products/libre-computer-board-roc-rk3328-cc

Renegade vs Pi comparisons follow.

4 core ARM Cortex-A53@1.512GHz vs 1.4GHz
28 nm vs 40nm process
LPDDR4 vs LPDDR2
USB 3.0 vs USB 2.0
dedicated Gb ethernet vs Gb ethernet over USB 2.0
MicroSD UHS support vs none
crypto extensions vs none

The Renegade probably has a better GPU and has options for 2 or 4 GiB of memory. This SBC is superior in most ways but there is one huge difference. It is not compatible with the Raspberry Pi and therefor lacks software. The Raspberry Pi is probably in more danger from competition than people involved with the project would like to admit though.

@matthey
Compatibility have to suffer to some degree to make a modern system and if then x86 or ARM is running the show doesn't really matter. Old programs can be made to run via emulation mostly seamless so again what architecture is underneath doesn't make much of a difference.

There's one big problem with x86: new code would logically use little endian data so using something with both new and old programs can cause troubles. ARM and RISC V can theoretically run big endian but IIRC some implementations doesn't really support it. Standardizing on little endian would open up to a multi-architecture design with AMD64, ARM64, and RISC V as potential targets possibly in heterogeneous configurations.

Without money to develop either a new OS or a new 68k core it doesn't matter much... :(

Quote:

davidf215 wrote: Is breaking backwards compatibility really a big issue considering 68k JIT and emulation are viable options for older software? Microsoft Windows and IBM OS/2 were able to add memory protection while allowing older software to run in isolated memory locations while helping to prevent crashing the OS. If Windows and OS/2 were able to do it, then AmigaOS should be able to do so as well. I would suggest to simply make the break, enhance JIT, and move on. Dave Pleasance has even said that, in time, the AmigaOS would have an end of life cycle and need to be replaced, so breaking backwards compatability with 68k via JIT is a good way to move forward.

Was emulation good enough to move 68k Amiga users to PPC? It helped but more stayed or moved to UAE. If you like the emulated sandbox, try starting a separate UAE instance for each Amiga program you want to run and see how you like it. The beauty of the Amiga includes multitasking, messaging, integration, shared resources and efficiency.

Quote:

If this is true, then it's interesting as to why Motorola hasn't released a multicore 68k chip.

Corporate Politics, hype, laziness and then the “don’t eat your own children” principle. Motorola joined the AIM alliance in the middle of the RISC hype and started pushing PPC. They didn't have to do all the work as specifications and shared development came from outside. Simple RISC CPUs are easier and faster to develop. The 68k was falling behind the x86 on the desktop due to die shrinks from economies of scale. Sadly, early PPC CPUs didn't do any better at performance. The 68060 was clock for clock similar integer performance to the 601 and outperformed the 603 and 603e. It was also clock for clock better integer performance than the most comparable Pentium. The superior performance was usually with half or less of the instruction fetch and memory bandwidth of the competitors and little compiler support. The 68060 was too competitive though. It was discouraged for desktop use but still was successful enough for embedded use that it eventually received a die shrink but the full model did not receive a higher clock rating (most rev6 68060s clocks over 100MHz and could have easily been rated 75MHz). Motorola did not want it competing with the PPC so it was a victim of “don’t eat your own children”. It was in the dog house where it stayed ever since despite the amazing performance and energy efficiency. Motorola was spun off into Freescale and bought by NXP. They are really lazy now taking prepared ARM CPUs and mixing and matching with other canned logic. I don't think they really do any CPU design anymore. The embedded market is profitable enough that they would rather pay the ARM license and use their prepared cores than develop what they own.

The 68k may also have been a victim of the “don’t eat your own children” principle with the choice of 8088 CPU at IBM. There is a theory that the 68000 would have been too competitive with IBMs higher performance and margin minicomputers. This is suggested by Paul DeMone in the following article.

https://www.realworldtech.com/escape-from-x86/

Quote:

Rose wrote: Unlike Amiga companies, Intel and AMD have competent lawyers. It's pretty standard in these kind of contracts to have a safeguard that in this case would protect Intel's right to continue using AMD64.

The cross licensing contract is at the following link.

https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm

The relevant section is section 5 on termination. The way I read it, only in the case of a breach of this contract is the other party able to retain the license. "Termination Upon Change of Control" by either party automatically terminates the whole contract (see section 5.2c).

The contract could discourage potential buyer who would want to keep developing x86_64 CPUs but could be enticing for malevolent companies who would benefit from the demise of the x86_64 architecture like ARM, Apple, and IBM.

@matthey

Quote:

The 68060 was clock for clock similar integer performance to the 601 and outperformed the 603 and 603e. It was also clock for clock better integer performance than the most comparable Pentium.

You know, I think I remember reading about this back then. I guess it was decided by Hyperion to move on with developing AmigaOS on the 603e anyways since 68k production was possibly coming to an end. So is there any CPU that is still being produced that is close to the 68060 or the 68K product line (or backwards compatible with it)? I presume there is not, which is why Vampire isn't using one.

Quote:

You aren't going to unify Amiga users on an x86_64 AmigaOS. It didn't even work to unify Amiga users on PPC where better compatibility is possible. The largest group of Amiga users are still using the 68k and want compatibility even if an x86_64 is hidden somewhere underneath. Look no further than the success of the Vampire and attraction of the Natami (Natami "MX Bringup Thread" had 761487 views) which don't even have a good performance/price. The Amiga users who stuck with the Amiga primarily liked it because of the 68k and/or AmigaOS. Separating these two divides the community.

AmigaOS 4 on 68k may be a good idea, but would it really be a long term option considering the 68k isn't produced anymore?

Quote:

Corporate Politics, hype, laziness and then the ?don?t eat your own children? principle. ... The embedded market is profitable enough that they would rather pay the ARM license and use their prepared cores than develop what they own.

Quite a pitty really. That better technology gets put on the back burner and forgotten. Intel has been able to enhance it's old 8086 chipset through the years while Motorola gave up on its own.

Quote:

The 68k may also have been a victim of the ?don?t eat your own children? principle with the choice of 8088 CPU at IBM. There is a theory that the 68000 would have been too competitive with IBMs higher performance and margin minicomputers. This is suggested by Paul DeMone in the following article. https://www.realworldtech.com/escape-from-x86/

Great article. Lots to ponder. This article helps to support your thoughts on using Amiga in the embedded market, and it helps to support the concept of a low priced Amiga solution.

@matthey

Quote:

Was emulation good enough to move 68k Amiga users to PPC? It helped but more stayed or moved to UAE.

Most just left Amiga behind, and it had nothing to do with CPU architecture and everything to do with the Internet arriving to the masses and lack of memory protection in AmigaOS.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

megol wrote: Compatibility have to suffer to some degree to make a modern system and if then x86 or ARM is running the show doesn't really matter. Old programs can be made to run via emulation mostly seamless so again what architecture is underneath doesn't make much of a difference.

It is interesting that x86 and ARM retained compatibility as they upgraded and *not* with emulation. The compatibility of AMD64/x86_64 is probably most responsible for killing the Itanium which used "efficient" x86 emulation after billions of dollars in development costs (perhaps $10 billion or more). The biggest reason for the Itanic failure was lack of compatibility and software. AMD64 retained excellent compatibility and as a result had more software and more efficient software. Let's take a look at an AMD presentation (slide number 4) for AMD64.

Quote:

o Leverages existing infrastructure - Leverages infrastructure - thermal, enclosures, power, and BIOS o Runs existing 32-bit applications natively with unsurpassed performance - >20% increase clock-for-clock compared to AMP Athlon processor - No tools or O/S work needed o Runs existing 32-bit applications on 64-bit O/S - Take full advantage of 4GB local memory - Allows customers to migrate to 64-bit performance according to their schedule - Low learning curve for users and support staff

Opteron and AMD64 A Commodity 64 bit x86 SOC
https://www.lanl.gov/conferences/salishan/salishan2003/weber.pdf

ARM also retained compatibility by introducing new ISAs with modes. It is possible to use the original ARM32 on new AArch64 hardware. AArch64 is fat and all this baggage from previous ISAs adds up, especially for lower performance hardware, yet it was important enough to allow compatibility *without* emulation.

Some compatibility may need to be sacrificed for modern features. Don't underestimate the cost of breaking compatibility when more compatible options are available though.

Quote:

There's one big problem with x86: new code would logically use little endian data so using something with both new and old programs can cause troubles. ARM and RISC V can theoretically run big endian but IIRC some implementations doesn't really support it. Standardizing on little endian would open up to a multi-architecture design with AMD64, ARM64, and RISC V as potential targets possibly in heterogeneous configurations.

Little endian is bad for compatibility. AMD64/x86_64 and RISC-V are little endian. AArch64 is bi-endian but when big endian is wanted this is really weird mixed endian (code remains little endian) and it deprecates support to easily change the endian mode on the fly. It is really little endian with a few wires crossed for marketing to be able to claim it is bi and has big endian support.

Quote:

Without money to develop either a new OS or a new 68k core it doesn't matter much... :(

Even Bill McEwen and Fleecy Moss were able to come up with $5 million to buy the Amiga IP from Gateway.

Quote:

Little endian is bad for compatibility. AMD64/x86_64 and RISC-V are little endian. AArch64 is bi-endian but when big endian is wanted this is really weird mixed endian (code remains little endian) and it deprecates support to easily change the endian mode on the fly. It is really little endian with a few wires crossed for marketing to be able to claim it is bi and has big endian support.

First of all, the endian issue is a grossly overrated problem. It basically only exists in the Amiga world and that is because Amiga (the original company) designed an OS which exposed its internal data structures, which becomes a problem years later trying to migrate the design, especially in a world that is mostly a different endian and also may obey different alignment rules. Elsewhere this is not really an issue.

Second, it is more than a "marketing thing", ARM has selectable endian, whether it chooses to keep its instructions in the same endian does not really matter, we are not normally going to interpret its program as data, this is not Lisp.

By the way you talk, I suppose you are not a hardware designer, nor are you a tools maker...

A hardware designer loves weird hardware hacks that makes us tools makers shake our heads, then we just adapt and fix.

@hth313

the endian issue is real as it gets, its not issue if you have source code, se the PC programs and stuff ported from x86 linux to AmigaOS 68K and PowerPC.

also to a large exenet Amos Kittens will work on little endian, but it does this by converting the .amos file from big endian to little endian before it executes it. this will be ok for most Amos programs, but lot of amos programs loads up data files into banks of memory, and this is the problem, so you say but just make leek/loke big endian, but what do you do if you do,

l=loke(varptr(myvar))

Then myvar has little endian int, and loke does know not know its little endian data, but you see my point. the problem is mixing big and little endian, and its really hard to avoid when you porting over something, I have been think about this issue for many days now, and have come to no good solutions. beside people need to update there amos programs, the problem is not just solved by stuffing code on a different cpu.

the solution will be for banks you do LokeBE() and for variables you do Loke() (as it use what ever is native to CPU), and for x86 files (like wav files) you do LokeLE(), but this won't be backwards compatible, with AmosPro, as lokeBE and LokeLE don't exist there.

a where slow solution might be to check if address is variable or if its a bank and just do find function, check etch variable, check etch bank and so on. it slow as hell, as has do for etch leek(adr), maybe in a loop for large dataset. so auto detection is not a good idea.

bool is_var_adr(void ptr)
{
    for (n=0;n<var;n++)
    {
        if ((adr>=varlist[n].lstart)&&(adr<=varlist[n].end)) return true
    }
    return false
}


The end result, is that Amos Kittens on x86 will not be as compatible as Amos Kittens on PowerPC, where you have same big endien cpu like mc680x0 cpu every one loves.
Last edited by NutsAboutAmiga on 27-Feb-2019 at 07:31 PM.
Last edited by NutsAboutAmiga on 27-Feb-2019 at 06:38 PM.
Last edited by NutsAboutAmiga on 27-Feb-2019 at 06:32 PM.
_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

hth313 wrote: First of all, the endian issue is a grossly overrated problem. It basically only exists in the Amiga world and that is because Amiga (the original company) designed an OS which exposed its internal data structures, which becomes a problem years later trying to migrate the design, especially in a world that is mostly a different endian and also may obey different alignment rules. Elsewhere this is not really an issue.

The endian issue was not much of a problem on the Amiga until most of our software was little endian ports and there were Amiga flavors which were natively little endian (AROS x86_64). Code needs to be endian aware at this point which is more work and usually slower. Some coders on little endian systems are choosing faster algorithms and/or lazyness rather than endian awareness. For example, porting web browsers is more difficult because of this. More abstraction could have solved the exposure of OS internal data structures but it would likely also be slower. Even the Amiga tags system is significantly slower than accessing data directly in structures.

Quote:

Second, it is more than a "marketing thing", ARM has selectable endian, whether it chooses to keep its instructions in the same endian does not really matter, we are not normally going to interpret its program as data, this is not Lisp.

A 68k or PPC emulator creates ARM code which needs endian conversion because the code is little endian (data becomes code). ARM bi-endian support is weak and is being reduced. Whether it matters depends on the priority of compatibility. It may be better to break compatibility and do a proper little endian port to ARM.

Quote:

By the way you talk, I suppose you are not a hardware designer, nor are you a tools maker... A hardware designer loves weird hardware hacks that makes us tools makers shake our heads, then we just adapt and fix.

The mixed endian support seems like the weird hardware hack to me.

@Hypex 

Quote:

Yes it is. Called AmigaDE. IIRC it only ran on a PC. Well that AmigaDE we were given. That was never ported to OS4. Java is the same idea. Which is why I wondered back then why they were reinventing the wheel. But given how clumsy it is to run a Java program not in a web browser I could see how the user interface would be improved. Right now, JavaScript JIT has taken over. Which might deliver a superior experience. But it still looks inefficient compling from source at run time compared to loading virtual machine code directly. Cutting out a middleman or frontman.

The compile once run anywhere idea is great for developers. The AmigaAnywhere 2 concept of an AmigaOS emulated on other platforms would have been great for Amiga developers, too, in that making an app transparently run on any platform. I wonder if the AA2 code is floating around out there somewhere. Cloanto's AmigaForever is really close with its option to launch a game from within the app. All that would be needed is a wrapper to launch an Amiga app transparently on a host OS.

It would be nice to have a setup such that code written in C/C++ could compile (into bitcode) and run on popular platforms. Maybe the Hollywood app could add this as an add-on.

@matthey

Quote:

A 68k or PPC emulator creates ARM code which needs endian conversion because the code is little endian

Why would the emulator create the opcodes' bit patterns in big-endian in the first place, and then swap it so the little-endian instruction fetch gets what it expects? Why not simply create the bit patterns appropriately in the first place.

And let's be serious --- even if an emulator worked that way (maybe because it's based on some little-endian targeted project), reversing the bytes is a single cycle instruction which precedes the write-to-memory. Now, the write-to-memory goes into data cache, so before actually executing it, that cache needs to be flushed far enough down the hierarchy to find unified memory, and then the data cache needs to be reloaded from there. That single cycle is insignificant compared to the effort to create the word and get it into instruction cache.

Quote:

ARM bi-endian support is weak and is being reduced

Uhm, what makes you say that? ARM switched from BE32 (comparable to the PPC little-endian support, mucking around with A0 and A1 for byte or word sized accesses, and failing miserably on unaligned accesses, or those >32 bit) to BE8 (properly rearranging the bytes in actual memory, and transparently swapping data bytes on the way in and out) a few generations ago. How is that weak? And how is it being reduced?

@umisef

Quote:

Why would the emulator create the opcodes' bit patterns in big-endian in the first place, and then swap it so the little-endian instruction fetch gets what it expects? Why not simply create the bit patterns appropriately in the first place.

My m68k JIT for ARM does not do it :) I mean yes, I have endian swap macro but this is done by gcc during compile stage, so no endian swapping when JIT is working.

Actually the only single place where BE8 ARM code sucks are relocations. Since instructions are always LE, relocating branches means one has to convert opcode from LE to native format (BE), perform relocation, convert opcode from native to LE and write back to memroy. But hey, relocations are done only once when program is loaded, so it doesn't really matter :)

Quote:

Uhm, what makes you say that? ARM switched from BE32 (comparable to the PPC little-endian support, mucking around with A0 and A1 for byte or word sized accesses, and failing miserably on unaligned accesses, or those >32 bit) to BE8 (properly rearranging the bytes in actual memory, and transparently swapping data bytes on the way in and out) a few generations ago. How is that weak? And how is it being reduced?

Maybe matthey tries to point that, according to ARM Holdings, endian support of every ARM chip is not a mandatory thing, rather an option which vendors may use or not. But, to be honest, so far all ARM cpus I've tested do support switching from LE to BE8. Yes, it's harder on aarch64 (setend instruction is disabled) and can be hard on armv8-a (setend instruction is declared as deprecated and OS can either allow execution of setend or may generate exception on it).

BTW. In few days/weeks I will verify if RK3399 does support endian switching

@davidf215

Quote:

You know, I think I remember reading about this back then. I guess it was decided by Hyperion to move on with developing AmigaOS on the 603e anyways since 68k production was possibly coming to an end.

I think we could blame Phase5 for this one. Since they produced the PowerUP boards with the PowerPC. Which at the time would have been exciting with clock speeds like 160 to 240Mhz. Though I never had one in the day.

In retrospect it was an obvious choice. Mototola had killed off both the 68K and 88K follow up.
And PowerPC become top of the pops in the new RISC movement. Plus the Mac, the closest current computer to the Amiga, was using it. No doubt thanks to the AIM alliance.

The Amiga only lasted about ten years with the 68K, then lagged along with exclusive PowerUP boards for another ten, until the AmigaOne stamped us with PowerPC permanently along with OS4. Ten years later we are in trouble again. So the PowerPC gave us around 20 years of life before it was in trouble. That's a pretty good innings. Unfortunately just as we settled on it with OS4 Apple killed it off.

Had Phase5 gone in another direction and brought out a "PowerARM" instead, which suits the CPU extension reality, we could have been running OS4 on ARM chips now. Though I don't know if ARM was as developed back then in 1995 to be as powerful as a PowerPC.

It might have made more sense to stick a PA-RISC on board since it looks like this is where Commodore were heading.

Quote:

AmigaOS 4 on 68k may be a good idea, but would it really be a long term option considering the 68k isn't produced anymore?

Thus why Hyperion targeted the PowerPC. They first developed OS4 on actual Amiga hardware. And the only fast expansion was a PowerUP.

@matthey

Quote:

Little endian is bad for compatibility. AMD64/x86_64 and RISC-V are little endian. AArch64 is bi-endian but when big endian is wanted this is really weird mixed endian (code remains little endian) and it deprecates support to easily change the endian mode on the fly. It is really little endian with a few wires crossed for marketing to be able to claim it is bi and has big endian support.

I can see what you mean with endian mxed code. Or rather, code in an opposite endian. Such as what would happen on x86 or ARM. Though x86 is slightly more advanced as on top of byte swapping it can also read and write data in big endian format. So it can be optimised once more. No more excuses about TCP datagrams having big endian data being bad for x86. As if it really slowed it down. Now it can load it directly. Provided compilers support it directly, it's been in there over ten years now.

That said, a customised OS4 could be compiled for x86 that specifically used those BE instructions. As a work around. But the machine code would look weird and backwards. And doing so wouldn't help LE ports. Unless the compiler could switch endian.

The best move would be a rewritten OS4, perhaps in C++, with legacy PPC and 68K emulators built in.

Last edited by Hypex on 01-Mar-2019 at 04:35 AM.

About a new Amiga port for arm I think the best and fastest solution could be fix and add all needed OS features in one pass, breaking compatibility, and recompile all projects to run on new modern os.
No ppc emulation, no 68k emulation, only new recompiled native software.
If you want run old stuff you can choose between uae or qemu.

Arm can run memory read and writes in BE mode, but maybe could be better convert all os structures in LE mode and rewrite, possibly in Plain C, all internal structures.
It could be also future proof rewrite os whiteout any specific cpu in mind and write code in as much as portable.

But the most courageous thing could be free OS4 code and let a coordinated community to improve it for free, without loose legal rights on it.
I think this could be possible and could be a great chance to regain unity and wide interest about it.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@Hypex

Quote:

In retrospect it was an obvious choice. Mototola had killed off both the 68K and 88K follow up.

Yes, I think it was an obvious choice at that time, too. I do not remember much about ARM during the times when Apple was using PowerPC.

Quote:

The best move would be a rewritten OS4, perhaps in C++, with legacy PPC and 68K emulators built in.

This is my thought, too.

@Fl@sh

Quote:

No ppc emulation, no 68k emulation, only new recompiled native software. If you want run old stuff you can choose between uae or qemu.

I do agree with matthey and Hypex in regards to leaving 68k emulation in AmigaOS. Otherwise, many in the Amiga community wouldn't purchase it.

@davidf215

Quote:

I do agree with matthey and Hypex in regards to leaving 68k emulation in AmigaOS. Otherwise, many in the Amiga community wouldn't purchase it.

I agree, but even that is not enough. If a new port (or rewrite) doesn't run most of the apps that Linux runs then not many people will use it, since it would be better to just use Linux with FS-UAE, which we already have.

_________________
"Unix is supposed to fix that." -- Jay Miner

ARM has no worse bi-endian support than POWER/PPC. Mixed endianness is still ugly in my book. It is not just the code in the native CPU endianess but also SIMD instruction data, load/store multiple or special instructions, registers, MMU pages etc. which can be affected. Some instructions may have different behaviors in regard to alignment restrictions. The bi-endian modes are rarely a mirror of each other and one side is getting shorted in features and/or performance.

AArch64 did make many features standard but some of the big endian support is not part of the standard. Compatibility was very important for AArch64 initial acceptance but I expect less used optional and/or legacy features like BE support will be removed over time.

Quote:

Hypex wrote: I think we could blame Phase5 for this one. Since they produced the PowerUP boards with the PowerPC. Which at the time would have been exciting with clock speeds like 160 to 240Mhz. Though I never had one in the day. In retrospect it was an obvious choice. Mototola had killed off both the 68K and 88K follow up. And PowerPC become top of the pops in the new RISC movement. Plus the Mac, the closest current computer to the Amiga, was using it. No doubt thanks to the AIM alliance.

PPC made sense for the desktop after the 68k (unless C= had been able to license the 68k and stay in business). Motorola was pushing PPC as a replacement and it was better suited for the desktop than the embedded market. It didn't make any sense to kill off the 68k, ignore its strengths and ignore its embedded customer base who realized its strengths and loved its ease of use. Imagine if Intel had killed off x86 when they brought out the Itanium. They would have been devastated by AMD like Motorola/Freescale was by ARM taking the embedded market.

Quote:

The Amiga only lasted about ten years with the 68K, then lagged along with exclusive PowerUP boards for another ten, until the AmigaOne stamped us with PowerPC permanently along with OS4. Ten years later we are in trouble again. So the PowerPC gave us around 20 years of life before it was in trouble. That's a pretty good innings. Unfortunately just as we settled on it with OS4 Apple killed it off.

The "ten years" with the 68k were the golden years. It wasn't just Apple that killed off PPC. Intel with an ugly old CISC ISA that consistently outperformed PPC may have played a part.

Quote:

Had Phase5 gone in another direction and brought out a "PowerARM" instead, which suits the CPU extension reality, we could have been running OS4 on ARM chips now. Though I don't know if ARM was as developed back then in 1995 to be as powerful as a PowerPC.

That would be StrongARM.

Quote:

In early 1995, Advanced RISC Machines, Apple Computer, and Digital Equipment Corporation (DEC) announced that they would develop a family of ultra high performance, low power processors for PDAs based on the ARM architecture. DEC was able to bring to bear many of their experienced MPU designers who helped create multiple generations of microVAX and Alpha processors. A year later the StrongARM SA-110 appeared and set a new standard for embedded control processors.

ARM’s Race to Embedded World Domination
https://www.realworldtech.com/arms-race/

The high clock rates probably looked impressive back then. DEC had invested big money in fab technology for Alpha and applied the same technology to ARM. The comparison is really not so great.

Quote:

Once described as a processor successfully hiding in an SRAM, the 0.35 um SA-110 packed 2.5 million transistors (115,000 in the CPU) in a 50 mm2 die with 16 KB, 32-way set associative instruction and data caches, MMUs, and 128 byte write buffer.

The PPC 603 (shown on the chart above) was 0.5um with 1.6 million transistors. Of course it was short lived due to grossly inadequate caches. The PPC 603e was 0.35 µm, 2.6 million transistors and used a max of 4W at 80MHz or typically 2W (close to TDP). The big difference is that the 603e is still 3.3V.

P = CV^2f
P is power, C is capacitance, f is frequency, and V is voltage

The StrongARM SA-110 is 1.65V to 2V which saves power, especially at higher frequencies.

Now lets compare as close as we can the 68060. The 68060 is 3.3V, 0.6um, 2.5 million transistors, ~5.5W max. We can approximate the TDP by dividing 5.5W/1.5 which gives 3.7W. There were 2 die shrinks which we can estimate will drop power by about 75% giving 0.92W TDP @75MHz using 3.3V. Lowering the voltage should have made the 68060 competitive in power use with the StrongARM SA-110 but the 68060 would have had better energy efficiency because it had better single core single thread performance. Intel claimed 230 Dhrystone 2.1 MIPS @200MHz where the 68060 should have been 293 Dhrystone 2.1 MIPS @200MHz provided it did not get any performance boost from the 2 die shrinks other than a clock increase. This should allow the 68060 to be clocked 22% lower and give the same performance which further reduces power.

The StrongARM SA-110 was right before Thumb came about in the very popular for embedded ARM7TDMI. The article linked above states the following.

Quote:

Thumb is a rather clever feature that adds very little complexity to an ARM7 MPU, only about 3000 transistors. Yet Thumb improves ARM instruction density (already quite good, roughly comparable to 32-bit x86 code) by about 25 to 35%. Not only that, but in systems with 16-bit wide memory (not uncommon in cost sensitive embedded applications) an ARM7 would run an application compiled into Thumb faster than if it had been compiled for 32-bit ARM code.

This is just plain wrong about ARM32 code density being "already quite good, roughly comparable to 32-bit x86 code". ARM32 code is a little better than PPC code in code density and x86 code density is likely at least 20% and probably more like 25% better than ARM32 code density. Code density allows the caches to be smaller and faster. It is a major reason why the 68060 outperformed these RISC CPUs and why ARM Thumb/Thumb2 were so popular for embedded. While Thumb2 gives code density comparable to the 68k, it also increases the number of instructions and memory traffic offsetting some gains. The 68k does not suffer from these issues and has room to improve code density.

Quote:

It might have made more sense to stick a PA-RISC on board since it looks like this is where Commodore were heading.

PA-RISC was more dead end than PPC. The designs were simple, the CPUs were lagging on die shrinks and the code density was very poor. I did a comparison on EAB showing how the 68060 outperformed early PA-RISC CPUs which were higher clocked and more expensive.

http://eab.abime.net/showpost.php?p=1142968&postcount=22

@matthey

I actually have a StrongARM machine in the closet, but I am not using it at the moment.

PA-RISC was earlier than PPC, and was more in the same era as Sparc. I believe it was faster at the low end at least. I have not studied it in depth, I was just a user of them. Both PA-RISC and Sparc were replacements for the 68k series in the workstation market. PPC ended up being more of a competitor to x86 in the desktop market, perhaps due to the changing times, I do not remember that so well, I never used PPC computers at the time.

At this time x86 was for low performing PCs with its sad excuse of an operating system. Workstations used something else and there was a clear divide between workstations and PCs. It is very different today.

It is no surprise that Commodore was going for PA-RISC at the time, as they had ties with HP.

In retrospect, the only real mistake I think one can blame anyone here for, is Motorola for giving up the 68k market, at least the embedded side. That was a huge mistake which they should have been able to see at the point. Instead they pushed new designs on the market, and few had much success. The only minor excuse (or explanation) for dropping 68060 and beyond I can grant them, is that at the time it was strongly believed that RISC would win over CISC.

You give convincing arguments, any success applying that on potential chip makers for 68k?

Last edited by hth313 on 02-Mar-2019 at 03:28 AM.