@matthey

Quote:

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.

On ARM with big endian mode only instructions (for easy endian switching on the fly) and peripherals (this is quite obvious) stay in native little endian. Changed alignment was problematic in old days when so called BE32 mode was in use. Since BE8 was introduced the problem was gone.

Since endianess affects memory accesses only, nothing changes with respect to special arm registers. When ARM cpu is told to run supervisor code in big endian mode, then the mmu page tables are expected to be in big endian too. I will check today how (and if) endianess affects fpu data types.

All I wrote is valid for aarch32. Soon I will test how it changes on aarch64. But, even if it changed there, there is no need to worry about endianess of amiga-like systems beyond 32-bit...

@matthey
Quote:

matthey wrote: 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.

The big thing about x86 have been the backwards compatibility so of course AMD wanted to show that their extension was compatible. But it was also not completely accurate as real mode (segmented 16bit* mode as in the 8086) wasn't supported and would require emulation. Note that e.g. Windows simply dropped MSDOS support in 64 bit installations for this reason.
So even the architecture that have kept compatibility even when requiring extra effort have dropped complete compatibility.
(* undocumented but supported is also a 32bit mode a.k.a unreal mode/extended real mode)

However this is all something not really related to what I wrote which was about the Amiga situation. We have an operating system that doesn't support some things people expect, that makes porting software harder than necessary and was designed for an architecture that is long gone. So a modern update will need to break compatibility for several reasons so that software can be ported and that a user will be able to connect to the internet without worrying that even a scriptkiddie could read all their private data.

But breaking compatibility doesn't mean old programs can't run just as MSDOS programs could be run on a native 32bit operating system. Of course there would need to be an emulator to run 68k programs on e.g. AMD64 but they could still be part of the system.

Quote:

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.

I wouldn't call AARCH64 fat, what designs are you comparing to?

Quote:

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.

Protection requires breaking compatibility to some degree, there's no alternative. Increasing software availability by making software porting easy will most likely require going from a single address space design to private address spaces, this is a significant change and will break compatibility. Resource tracking could be retrofitted with minor changes (some incompatible) but going for private address spaces as mentioned above would make it easier.

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 wouldn't call that mixed endian and even if it were proper (I reserve it for the PDP11) it doesn't matter. Why should the instruction bits change order when changing endianess? Also are AMD64 REX prefixed instructions BE because the highest register bits come before the lower bits?

Yes it's bad for compatibility but that's the state of things. When even IBM move towards LE and all new designs are either natively or generally run as LE one have to accept it as a fact.

Quote:

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

That's an indication there were some interest many years ago, the recent payment of back taxes is also an indication of something.

Quote:

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

Instructions are a bunch of bits, adding expensive hardware in the decoder because you want the bits nobody ever looks at to be nicely ordered would be very weird.

@bison
Quote:

bison wrote: 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.

Replace Linux with Windows and FS-UAE with WinUAE to make it more relevant. But if one just want a Linux install it's already here as you wrote, why do anything more than a Amiga inspired shell if this is the goal?

@michalsc

Quote:

I will check today how (and if) endianess affects fpu data types.

Checked. When ARM cpu is put into big endian mode the VFP registers are also read/written from/to memory in big endian fashion.

@megol

Quote:

Quote: bison wrote: 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. Replace Linux with Windows and FS-UAE with WinUAE to make it more relevant.

There is source code available for WinUAE (I assume), but not for Windows, so there's only so far you can go with it. One would not be able to modify or replace the default desktop environment, for example.

Quote:

But if one just want a Linux install it's already here as you wrote, why do anything more than a Amiga inspired shell if this is the goal?

A new shell would be a start, but it would be better to go further and create a new GUI toolkit so that new apps could be written. I have similar ideas as what others have suggested, the only difference is that I think it's better to go top-down rather than bottom-up with a completely new OS. That way existing apps from the host system can be used while new apps are being written.

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

Quote:

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

StrongARM and the followup XScale were popular as Intel acquired the line from DEC in 1998. The XScale assets were sold by Intel for $600 million in 2006.

Quote:

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.

PA-RISC was introduced in 1987. It was certainly faster than the stack architecture RPN (like many HP calculators) minicomputers before it. The PA-RISC line continued all the way up to 2005 but the later computers were providing PA-RISC compatibility while HP transitioned most customers to Itanium and then x86_64. The PA-RISC was more about being simple but this probably hurt it more than helping it. For example, designs tended to use large L1 caches and no or off chip L2 which reduced performance and limited clock speeds (it needed large caches but failed to follow Alpha's example of using multi-level caches to reduce cache latencies). It was one of the first ISAs to add SIMD instructions but supported few datatypes and so their advantage was quickly eclipsed. The CPUs were for expensive minicomputers, workstations and servers but generally had unimpressive performance for the price.

Quote:

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.

x86 remained surprisingly competitive despite only 8 semi-GP registers and about every other instruction using the stack. After the 68k years, Alpha was the only architecture which had a sizable performance lead on x86 and that was with trade-offs which made it run hot and high transistor counts which increased production costs. Alpha CPUs were not friendly or cheap to adopt and had little software. Alpha's lead did not last long. There really weren't other computers except mainframes which took up whole rooms. After the 68k, workstations used different RISC CPUs which reduced economies of scale and allowed PC x86 economies of scale to replace them. ARM used embedded market economies of scale to become competitive in low power applicaitons after Motorola abandoned the 68k embedded market.

Quote:

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.

Even Intel thought the x86 would be replaced over time. Itanium was their replacement until AMD successfully introduced AMD64.

Quote:

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

Not likely. Most chip designers like their ARM a la carte. ARM makes it easy with designs prepared for different fab processes and options. ARM licensees don't have to do any CPU design. Freescale/NXP is likely the only chip design business who might be convinced (highly unlikely) to take a second look at the 68060 but they are happy to pay license fees to ARM as they have practically retired the PPC and ColdFire architectures too. ARM is so prolific that they are hurting CPU design innovation. There are some people who want other options like open cores but so far they have worked on very simple CPUs. Business partnerships could share costs and production as I have suggested in the past.

The 68060 was late to market and the Pentium Pro was 6 months early. The quick Intel die shrinks and performance upgrades quickly made the low clocked 68060 look poor performance. Motorola joined the AIM alliance and upper management decided to push PPC. Motorola employees even mentioning comparisons or evaluations of the 68060 were likely ostracized. AIM made some sense as adoption and unification on one architecture for the desktop was needed for economies of scale and software support. Still, it is amazing to me that Motorola engineers could work together to design these amazing and complex chips yet make big mistakes by not understanding their own products. The PPC 603 is a good example where the 8kiB instruction cache on the 68060 is like a 4kiB cache on the PPC with its lack of code density. Another example is the removal of 32x32=64 multiply in the 68060 as GCC was using it to optimize divide by a constant to multiplication and other "simple" CPUs were adding it like the StrongARM SA-110 we just looked at. Also, the 68040 removal of the FINT/FINTRZ FPU instructions has to be one of the biggest blunders ever as C compilers make heavy use of it. Management made mistakes and it resulted in the demise of one of the great U.S. businesses.

Quote:

michalsc wrote: On ARM with big endian mode only instructions (for easy endian switching on the fly) and peripherals (this is quite obvious) stay in native little endian. Changed alignment was problematic in old days when so called BE32 mode was in use. Since BE8 was introduced the problem was gone.

GCC developers talk about problems in BE mode.

Quote:

One notable exception to this though is the movmisalign patterns: these are implemented using the vld1 and vst1 instructions, which load elements in "array" order (increasing elements from increasing memory locations), even in big-endian mode. Since vectors loaded using those instructions are "incompatible" with the above scheme, such misaligned accesses are simply disabled in big-endian mode. Of course, generally, sticking with the current non-solution in big-endian mode is not sustainable (and is probably already broken in various cases). So it might be worth thinking about whether supporting big-endian mode properly, as well as handling the more complex load and store element/structure instructions, can be done using some generalised solution.

https://lists.linaro.org/pipermail/linaro-toolchain/2010-October/000360.html

The LLVM developers also talk about different behavior between LE and BE modes.

Quote:

If it works on all targets with Neon, regardless of the SCTLR.A setting, then I still don't see the need for a separate flag. Note that this won't work on big-endian targets where changing the vld1/vst1 element size actually changes the behavior of the instructions.

http://lists.llvm.org/pipermail/llvm-dev/2012-September/053168.html

It looks like ARM has less problems than POWER when in non native endian mode but there still may be potential problems. ARM BE mode support is not as well tested as POWER LE mode support so there could be problems with ARM BE compiler support and ported ARM LE programs.

Last edited by matthey on 03-Mar-2019 at 05:59 PM.
Last edited by matthey on 03-Mar-2019 at 05:57 PM.

@matthey

Quote:

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.

And also we must mention the abominable love child of 68K, so to speak, the ColdFire 68K. Taking the name and place of the 68K but being incompatible with it and speed limited. Being like the Amiga put against the AmigaOne.

Quote:

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.

I would have like to see that!

I suppose it would have depended how Intel developed the Itanium. People always speak against it by calling out the compatibility card. But, Apple shifted ISA, without major trouble. The x86 ISA was given to Intel to develop and produce, so it had its time, and it made sense to put it to rest and move on. I've previously stated, regarding the Itanium, that a redesigned Amiga could have used an Intel as a new CPU. A new Amiga running on an Intel, but it still wouldn't be a PC!

But of course AMD couldn't let x86 go. The most major feature AMD has contributed to x86 would be AMD64. They've made head way with the Ryzen series, but apart from that are generally considered inferior to Intel. And Intel has always had a head start with programs that purposely target Intel only. So much for compatibility and having free choice of what CPU brand you like.

Quote:

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.

The golden years yes. Though I would say the Amiga barely lasted five years before it was in trouble. Sure the A500 was a huge success. But in 1987 256 colour palettes were becoming standard and by 1990 24-bit framebuffers were in existence. Things move fast in the Amiga world. And in the 90's it became fashionable to replace Amiga graphic, sound, and other chipsets with cards that featured off the shelf chips.

By that stage with Apple, they had managed to replace Mac OS with OSX. And with OSX being portable they were able to make that decision to switch. Even if they did stuff like hack AIFF to be LE compaible.

Quote:

That would be StrongARM.

Well yes I suppose it could have been. Though using that name may not have been allowed. And PowerPC did give an emphasis on Power as hook.

@matthey

It didn't make sense to kill off the 68k line? Maybe Motorola saw 90% of the profits were from the embedded sector using a limited set of instructions which meant culling the 'desktop' / 'console' focused 68k processor down to the Coldfire. Probably made sense on paper. Also, PPC got IBM and Apple interested but now seems to be a shadow of its former self. The Cell got Toshiba, IBM and Sony pushing in the same direction and that really was a dead end.

Commodore really were clueless considering they bought MOS and should understand the value of developing a series of upgraded chips. They couldn't even evolve Paula and outsourced AGA custom chip production to HP. They couldn't put ANY pressure on Motorola to keep 68k alive because the were moving to HP's HP-PA chip. Amiga 68k was to be retired, the custom chips were a dead end and what we know would have been emulated. We are now pushing 68k again because half of us never moved to the AmigaOne platform but seriously where are the Vampire boards and why do we always have to pre-order?

Last edited by BigD on 03-Mar-2019 at 10:57 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

I think 68k reborn is really a nice dream, I really hope someone will read mattey posts and will contact him to make dreams come true.
The only things who separate us from ours dreams are our actions, so we need to make something concrete in that direction, now.
All us have an happy ending in our Amiga dreams and it’s the platform reborn.
I think The easyest way to realise it is a port of aos4 to arm, possibly on next RPi platform. We have discussed pro and cons prior in this thread

Once got it we can speak about add custom chips and others fancies that ever differentiated us from others.

If p68k reborn project will ever be true, we could consider a new os porting.

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

@BigD

Quote:

Commodore really were clueless considering they bought MOS and should understand the value of developing a series of upgraded chips. They couldn't even evolve Paula and outsourced AGA custom chip production to HP.

During the time when the Amiga was introduced, the Chip industry went from NMOS technology to CMOS. The internal construction of logic gates changed totally and Commodore never put some money into their own chip company to make it 'up to date'.

@BigD

there are several thousands boards sold already, that is a lot for such a small market. And only a fraction of the user base moved to PPC, most stayed on 68k amiga or simply left the market

The custom Amiga chips had their time. The industry eventually produced better chips.

@OlafS25 
Quote:

there are several thousands boards sold already

Wow, thousands? That's encouraging to hear. Maybe by the time Amiwest 2019 arrives A-Eon will deliver the first Enhancer Pack for OS3.

@Fl@sh

Quote:

I really hope someone will read mattey posts and will contact him to make dreams come true

I have read them, few years back in different threads, and have discussed possibilities with @matthey.

I'm not against the idea of someone else beating me to the proverbial punch, but my plan is to invest in reigniting the 68k revolution. Unfortunately, I won't be ready to do so for another couple of years.

_________________
All the way, with 68k

Quote:

Hypex wrote: a redesigned Amiga could have used an Intel as a new CPU. A new Amiga running on an Intel, but it still wouldn't be a PC!

But just having a new CPU isn't enough. To be price competitive your 'Amiga' would also need to work with the same graphics cards etc. as a PC, so it would need to be 100% PC compatible - IOW it would be a PC.

Quote:

But of course AMD couldn't let x86 go.

Of course not, because x86 compatibility was essential and any deviation was doomed to fail. Everyone knew that even before the A1000 was released. Amiga was a dead man walking from day one.

Quote:

The golden years yes. Though I would say the Amiga barely lasted five years before it was in trouble.

Actually it was in trouble right from the start. The A1000 was released 2 years before the OS was finished just to try to get a foothold in the marketplace, and even at that early stage the lack of IBM compatibility was an issue.

Quote:

Sure the A500 was a huge success...

...in Europe, where cheap PC clones hadn't yet arrived. But it never made it in the US - because it wasn't a PC.

Quote:

But in 1987 256 colour palettes were becoming standard and by 1990 24-bit framebuffers were in existence.

IBM introduced VGA in 1987 with their PS/2 line, which were horribly expensive and used an incompatible bus. The main attraction of VGA was not 256 colors (in 320x200 low resolution only) but the flicker-free high resolution 16 color graphics and text that business users liked. SVGA cards introduced 256 colors in hi-res, but performance sucked. SVGA didn't hit it's stride until 486 motherboards with VL bus arrived in 1992, but that didn't matter because you didn't need 256 colors to run Microsoft Word and Excel. Business software compatibility was always the driving force for hardware development in the PC world, and anything different was never going to make it.

Quote:

Things move fast in the Amiga world. And in the 90's it became fashionable to replace Amiga graphic, sound, and other chipsets with cards that featured off the shelf chips.

Not really. Very few of us bothered to install such expensive and unnecessary hardware, and then only because Commodore was long gone so it was the only way to upgrade our ancient machines. - until now!

Quote:

OneTimer1 wrote: Commodore never put some money into their own chip company to make it 'up to date'.

Why should they have? Most other chip 'manufacturers' went fabless because it was cheaper and safer than trying to make their own ICs.

Quote:

bhabbott wrote: Quote: But of course AMD couldn't let x86 go. Of course not, because x86 compatibility was essential and any deviation was doomed to fail. Everyone knew that even before the A1000 was released. Amiga was a dead man walking from day one.

Apple proves you are wrong.

Quote:

Quote: The golden years yes. Though I would say the Amiga barely lasted five years before it was in trouble. Actually it was in trouble right from the start. The A1000 was released 2 years before the OS was finished just to try to get a foothold in the marketplace, and even at that early stage the lack of IBM compatibility was an issue.

There were the side-car and the bridge-board, but I think it may have made more harm than doing good.

They can hardly sit on a useful piece of technology because the software in hindsight was not finished. What software is ever finished? And as the saying goes today, if you are not embarrassed when you launch your product, you have waited too long. You need to get it out and listen to your customers. Minimum viable products...


Quote:

Quote: Things move fast in the Amiga world. And in the 90's it became fashionable to replace Amiga graphic, sound, and other chipsets with cards that featured off the shelf chips. Not really. Very few of us bothered to install such expensive and unnecessary hardware, and then only because Commodore was long gone so it was the only way to upgrade our ancient machines. - until now!

Hardly unnecessary hardware. I got a graphics card to turn my A3000 into a very useful NetBSD box running XWindows. It gave it an additional 3-4 years additional life span.

Quote:

BigD wrote: Also, PPC got IBM and Apple interested but now seems to be a shadow of its former self. The Cell got Toshiba, IBM and Sony pushing in the same direction and that really was a dead end.

Yep. Anything that wasn't a PC was doomed to fail.

Quote:

Commodore really were clueless... They couldn't put ANY pressure on Motorola to keep 68k alive because the were moving to HP's HP-PA chip.

They might have sold more of one particular 'computer' than any other company on the planet, but they didn't make much out of it and never had the clout to put any pressure on chip manufacturers. But did anyone? The only thing putting pressure on was PC users.

Quote:

half of us never moved to the AmigaOne platform

Why would we buy an overpriced dead end that's an Amiga in name only, when we still have our real Amigas?

Quote:

but seriously where are the Vampire boards and why do we always have to pre-order?

They are being made as fast as the Apollo Team can without investing millions in large-scale manufacturing. Considering that (according to some) only a handful of serious users are left, that is the sensible thing to do. The fact that they sell out so rapidly just proves the market is much larger than expected.

But hey, pre-ordering is an Amiga tradition! I had to wait 2 years to get an Amiga 1000, and nearly a year to get my A3000. Then there was the Pheonix board I put a deposit on and never saw. But I bought my Vampire from Vesalia simply by waiting until it was in stock.

Quote:

hth313 wrote: Apple proves you are wrong.

If Apple had stuck to Macintosh they would have failed, and they nearly did. The only thing that saved them was moving out of the PC market into phones etc..

Quote:

There were the side-car and the bridge-board, but I think it may have made more harm than doing good.

I agree. They should have dropped the Amiga entirely and just concentrated on PC clones. But of course then we wouldn't have the best home computer ever made. I will be forever grateful to the guys at Commodore for ignoring their bottom line and producing such an amazing machine just for us!

Quote:

They can hardly sit on a useful piece of technology because the software in hindsight was not finished. What software is ever finished? And as the saying goes today, if you are not embarrassed when you launch your product, you have waited too long. You need to get it out and listen to your customers. Minimum viable products...

The Amiga 1000 was buggy as hell even 2 years after launch. They got away with it because back then enthusiasts were willing to put up with a lot to get their hands on the latest technology. If you tried to do that today it would be a disaster and you would be laughed at (and probably sued out of existence).

Quote:

Hardly unnecessary hardware. I got a graphics card to turn my A3000 into a very useful NetBSD box running XWindows. It gave it an additional 3-4 years additional life span.

I had a graphics card and 060 CPU in my A3000 too, but it wasn't necessary. The graphics card was only really needed for web browsing, so what I should have done was just use a PC. Eventually I sold my A3000 because too many websites were inaccessible. The problem as ever was... PC compatibility!

Last edited by bhabbott on 05-Mar-2019 at 08:39 PM.

@bhabbott

Quote:

I had a graphics card and 060 CPU in my A3000 too, but it wasn't necessary. The graphics card was only really needed for web browsing, so what I should have done was just use a PC. Eventually I sold my A3000 because too many websites were inaccessible. The problem as ever was... PC compatibility!

I can't see how that problem is solved with PC compatibility The Mac (PPC), Linux (Arm, PPC) and RiscOS (Arm) all run web browsers despite not being x86-64 PeeCees! The websites were inaccessible because Amiga developers could not get enough Amiga users to pay them to continue to develop their web browsers! Simples. The PC was never the be all and end all of computing it's just the Americans would prefer us to all accept their most successful computer paradigm despite also quietly designing the best in the Amiga.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

Quote:

OlafS25 wrote: there are several thousands boards sold already, ...

Please show me a trustworthy source for this claim.

Every time I was asking for a source about Vampire numbers, I was ignored.