[Bloomberg] Apple starting process to dump Intel in Macs

[ultimatebob]

Leopard was the last OSX release to support PPC, not SL.

Yeah... and many Mac software developers stopped supporting the Power PC platform long before Apple stopped patching the OS.

I know that I personally got screwed by this. I bought a G4 powered Mac Mini in early 2005, and the last OS upgrade that they offered for it was in 2007. They completely stopped offering patches for it in 2009.

 

[PeterScott]

^^

IIRC, the Sea of Cores patent talked about executing x86 instructions on non-x86 cores. Vice-versa would make sense as well. But I think this is an actual real ARM core either on die or off on it's own tile that the x86 core could utilize.

The specific thing I saw being removed was the MMX unit. Now, removing 16/32 bit support would make a ton of sense to Intel's server customers who don't want or need it. But if you break that, you may as well do a clean break. Maybe that's a part of it, that Intel made it obvious that the Lakes are just going to be milked with minor improvements at best and the Rapids won't be client-friendly...

IMO the main reason Intel would patent on chip x86 instruction converter for ARM, is to prevent that implementation by the ARM players, not because Intel intends to do that. Tons of stuff in patents never shows up in products.

The Chips and Bits rumor was the source of the MMX unit removal rumor. Still not a rumor that I put much stock in. I really don't think there is much to be gained here.

In theory Intel could do a ton of profiling and figure out which instructions/modes are seldom used, so they could be emulated in SW, then streamline the core, and provide some OS hooks, to emulate them in SW when called.

But that really doesn't really make for performance gains, just a small amount Core area savings, which really isn't a big issue these days. Most of an Intel mainstream CPU die these days, is Uncore.

 

[IntelUser2000]

Perhaps removal of some of the older units can reduce verification time. That is much more important than little area savings. If they can improve performance of the critical pathways, or make newer features easier to implement, it would be worth it. Just guessing.

 

[NostaSeronx]

Imsys' IM3000 with ISAJ(Java-byte ISA) and ISAL(LLVM-IR ISA) so far is pretty good for CISC overall.
https://www.eetimes.com/document.asp?doc_id=1327337
https://i.imgur.com/VkgG9cv.png

Imsys processors routinely switch dynamically between instruction sets, totally defined by microcode. The processor is runtime reconfigurable and new instruction can be added at anytime

If you research the Proof of Concept and everything else. Now look at Intel's modified VISC(SoftMachines patents -reapplied and -regranted with new info and figures)patents.
HVM -> Java, etc
LVM -> LLVM, etc
AVM -> x86 or ARM or anything(SPARC, POWER, etc)
NM -> Native ISA that covers all the above.(IM3000 ISAJ/ISAL)

I wonder who Intel is going to buy next.

Also, MMX/SSE/VEX are going to be completely gobbled up by EVEX. EVEX re-vectorization is free. (Re-vectorization is anything going from one SIMD ISA to another SIMD ISA, etc.)

 

[ksec]

Perhaps removal of some of the older units can reduce verification time.

Those were my thoughts as well. The complexity becomes exponentially hard to manage. And one of the few reason why the ARM team stick with no SMT.

And I think it will be a much better fit for server application, where everything is contained and well managed.

I kind of liked the Intel CPU decoding ARM instruction idea. But surely that is only in flavour of Apple and not Intel. I am not sure of what Intel has to gain in there.

 

[IntelUser2000]

I kind of liked the Intel CPU decoding ARM instruction idea. But surely that is only in flavour of Apple and not Intel. I am not sure of what Intel has to gain in there.

Well, Intel is a big enough company where their sole concerns aren't entirely about Apple. Apple is also diverging from Intel because they want the control of the whole stack. I don't think it would have mattered in the long run whether Intel won the original iPhone or not. Apple may have turned to internal teams regardless of what Intel did initially.

Right now the decoders in Intel CPUs take x86 instructions and convert them into simpler internal instructions. Hence the talk of Intel CPUs being x86, but RISC inside. If they can also decode ARM instructions to the same internal instructions, then they'd have something big. They won't need binary translation like they used when Atom Android phones were a thing. They can just aim the chip at whatever is required - ARM or x86.

That's assuming its technically feasible to make a decoder that's proficient in decoding ARM instructions and x86 instructions, and do it without noticeable performance loss. This is the IF.

 

[Ajay]

They are working to eliminate BIOS support and move to UEFI. It also seems logical to eliminate 16/32-bit support. This isn't a rumor, its being worked on.

What is a rumor is a CPU that is supposedly being worked on that can decode ARM instructions to x86.

Getting rid of 16 bit support in x86 would probably be fine. There are still a ton of software that uses 32 bit code - there would need to be some sort of emulation built in to eliminate native 32 bit execution.

 

[Drazick]

Getting rid of 16 bit support in x86 would probably be fine. There are still a ton of software that uses 32 bit code - there would need to be some sort of emulation built in to eliminate native 32 bit execution.

This is the problem, looking at the current state and causing problem in the future.
So what if there is ton?
If something is missing it means it will create a new demand for new solutions, hopefully better.
This is where Apple excel, leave the past behind and move forward.

It's not like there is no solution.
Intel could always say the last CPU with 16 and 32 Bit support is <Name Here>.
It will be manufactured for 10 years (Like LTS CPU).
Probably it will run this code fast and good enough that for all those who care it will be more than enough.

Move forward, stop carrying luggage everywhere.

 

[PeterScott]

This is the problem, looking at the current state and causing problem in the future.
So what if there is ton?
If something is missing it means it will create a new demand for new solutions, hopefully better.
This is where Apple excel, leave the past behind and move forward.

It's not like there is no solution.
Intel could always say the last CPU with 16 and 32 Bit support is <Name Here>.
It will be manufactured for 10 years (Like LTS CPU).
Probably it will run this code fast and good enough that for all those who care it will be more than enough.

Move forward, stop carrying luggage everywhere.

That might work for Apple. Where users seem to get used to buying all new SW/HW on a regular basis, but the major strength of Windows is the huge backward compatible software library.

No way in hell would I buy PC HW that couldn't run 32 bit software (or that ran it slow). Most of my games library is 32 bit, and I like playing older titles a lot.

 

[William Gaatjes]

Imsys' IM3000 with ISAJ(Java-byte ISA) and ISAL(LLVM-IR ISA) so far is pretty good for CISC overall.
https://www.eetimes.com/document.asp?doc_id=1327337
https://i.imgur.com/VkgG9cv.png


If you research the Proof of Concept and everything else. Now look at Intel's modified VISC(SoftMachines patents -reapplied and -regranted with new info and figures)patents.
HVM -> Java, etc
LVM -> LLVM, etc
AVM -> x86 or ARM or anything(SPARC, POWER, etc)
NM -> Native ISA that covers all the above.(IM3000 ISAJ/ISAL)

I wonder who Intel is going to buy next.

Also, MMX/SSE/VEX are going to be completely gobbled up by EVEX. EVEX re-vectorization is free. (Re-vectorization is anything going from one SIMD ISA to another SIMD ISA, etc.)

That is strange, you must have given the wrong link because the sentence you qouted, is not to be found in the links you provided.

Imsys processors routinely switch dynamically between instruction sets, totally defined by microcode. The processor is runtime reconfigurable and new instruction can be added at anytime

Imsys makes IoT microcontrollers. The only thing they mention is that all the instructions are microcoded in such a way they claim to have a power efficiency advantage.
And they compare to rather old arm architectures and other microcontrollers.

 

[Eug]

That might work for Apple. Where users seem to get used to buying all new SW/HW on a regular basis, but the major strength of Windows is the huge backward compatible software library.

No way in hell would I buy PC HW that couldn't run 32 bit software (or that ran it slow). Most of my games library is 32 bit, and I like playing older titles a lot.

At this point if I were to buy a new machine, I couldn't care less about legacy 32-bit software.

If there were some mostly-64-bit software that had a bit of legacy 32-bit code, I'd be fine with that even if it took a significant performance hit, as long as it ran fine. Computers are so fast these days that I don't care. I suspect that while I may not represent the enthusiast crowd, I probably do represent most of the mainstream market.

 

[PeterScott]

At this point if I were to buy a new machine, I couldn't care less about legacy 32-bit software.

I take it you don't have much of a PC games library.

 

[IntelUser2000]

I suspect that while I may not represent the enthusiast crowd, I probably do represent most of the mainstream market.

Do you represent everybody though?

Tech should be a black box and be transparent as possible. Enough people do care about compatibility that we have a divergence of usage between Windows and Android. I know when Vista came out there were applications that had problems running, and again with Windows 7. If merely switching to a newer OS will cause problems, taking out 32-bit entirely definitely will.

 

[jpiniero]

Do you represent everybody though?

Everybody using a mac... yes. The current version of macOS is the last that supports 32-bit apps "without compromise". Which in Applespeak means it will be gone in the next version or the version after that.

 

[PeterScott]

Do you represent everybody though?

Tech should be a black box and be transparent as possible. Enough people do care about compatibility that we have a divergence of usage between Windows and Android. I know when Vista came out there were applications that had problems running, and again with Windows 7. If merely switching to a newer OS will cause problems, taking out 32-bit entirely definitely will.

Good example. I remember Vista. People screamed bloody murder because a few things didn't work.

Wipe out a huge portion of peoples software libraries and the pitchforks would come out.

I suppose some people don't have any software except what came with their computer, but I wouldn't want to guess at numbers. One of my computer illiterate relatives that I gave an old computer to, surprised me by buying and installing some cheap programs/games he found in a departments store. Even he would probably be upset if the next computer he got wouldn't run any of it.

 

[PeterScott]

Everybody using a mac... yes. The current version of macOS is the last that supports 32-bit apps "without compromise". Which in Applespeak means it will be gone in the next version or the version after that.

Doesn't mean everyone with a Mac is happy about it.

Also My post already said that might work for Apple.

PC users are not so used to re-buying HW/SW to keep up with Apple, they are used to backward compatibility.

 

[whm1974]

Doesn't mean everyone with a Mac is happy about it.

Also My post already said that might work for Apple.

PC users are not so used to re-buying HW/SW to keep up with Apple, they are used to backward compatibility.

And the vast majority of PC users require backward compatibility as well.

 

[Eug]

I take it you don't have much of a PC games library.

I do not. However, even if I did have a legacy 32-bit games library, I'd just keep a legacy 32-bit-capable machine around to play it if I had to.

Do you represent everybody though?

Tech should be a black box and be transparent as possible. Enough people do care about compatibility that we have a divergence of usage between Windows and Android. I know when Vista came out there were applications that had problems running, and again with Windows 7. If merely switching to a newer OS will cause problems, taking out 32-bit entirely definitely will.

Very true. But at some point, they have to cut the cord. Again, we are talking here not about loss of compatibility, but loss of performance when running 32-bit software.

Considering 32-bit would be considered legacy in this hypothetical scenario, the machines will just need legacy levels of performance. Given that 2017 --> 2018 represents a huge jump in consumer CPU performance, this alone can compensate for this.

Everybody using a mac... yes. The current version of macOS is the last that supports 32-bit apps "without compromise". Which in Applespeak means it will be gone in the next version or the version after that.

Indeed, my two primary machines (both Macs) will be 100% 64-bit as of this fall.

My primary Windows PC is also 64-bit but if it went 64-bit-only, I'd have to buy new software licences. I'm still running Office 2007 on that machine. Mind you, if it just meant taking a performance hit, I'd likely be OK with that, since Office 2007 etc. is low impact enough that it'd run fine even with a 30% performance hit, especially considering that if I bought a new mid-range machine, I'd literally double my CPU performance compared to what I have right now (Phenom 1055T hex-core).

 

[IntelUser2000]

Good example. I remember Vista. People screamed bloody murder because a few things didn't work.

Wipe out a huge portion of peoples software libraries and the pitchforks would come out.

This annoys me too, because I have to deal with it.

Mac is easier to transition with their whopping 7% marketshare.

Again, we are talking here not about loss of compatibility, but loss of performance when running 32-bit software.

You cannot guarantee compatibility. Like I said, Switch from XP to Vista resulted in compatibility issues, because it represented a bigger than usual change in OS for Microsoft. 7 was smaller since it had the same core, but still had issues in the beginning. Those changes are insignificant compared to what eliminating the 32-bit portion would do.

 

[Eug]

Hmmm... I just realized that this fall, my Macs won't be 100% pure 64-bit. MacOS 10.14 will just give you annoying warnings if you try to install and/or run 32-bit software. So it looks like it probably won't be until fall 2019 before 32-bit is killed off altogether.

 

[VirtualLarry]

32-bit Windows applications (games, especially), used Win16 installers. And when most apps moved to 64-bit, they still now use 32-bit installers.

If you eliminated 32-bit mode, you would lose access to wide swathes of software, that were themselves, "64-bit".

 

[whm1974]

32-bit Windows applications (games, especially), used Win16 installers. And when most apps moved to 64-bit, they still now use 32-bit installers.

If you eliminated 32-bit mode, you would lose access to wide swathes of software, that were themselves, "64-bit".

Didn't 64 bit versions of Window had major issues due to this?

 

[Eug]

If Intel said to developers that 64-bit everything would be mandatory in 2022, they'd have to get their ass in gear to meet that deadline.

Somehow I just don't see everyone in the world switching to AMD over this.

 

[jpiniero]

PC users are not so used to re-buying HW/SW to keep up with Apple, they are used to backward compatibility.

True, but this thread is about Apple though.

 

[PeterScott]

True, but this thread is about Apple though.

The context was about Intel abandoning support for 16/32bit code with next generation CPUs.

That wouldn't only affect Apple. In fact it would have a much greater effect on Windows users, hence my comment.