Intel considering making new CPUs 64 bit only

[Berni]

Yep apples rosetta compatibility layer is surprisingly fast.

But since Apple makes both the hardware and the OS they had the motivation to put work into it. They no doubt had to have a sizable team of very bright people working on it.

Yet for Microsoft there is not much incentive to develop a high performance compatibility layer. They don't benefit anything from making Intel and AMDs life easier. Once they started messing with ARM they instead pushed for .Net JIT since that's the tech they already had available, so it takes the minimum amount of effort from there side to make apps run on non x86 systems.

Windows ARM was a spectacular failure that cost the company billions. It was a product called "Windows" that didn't support the vast library of "legacy" Windows software, it was blindingly obvious to me when I first heard it announced that it was going to fail. People buy Windows precisely because it has the largest library of software.

I agree. But this was already the case with Windows CE that had some kind of translation layer to mimic Windows. It wasn't Windows at all; you'd have to rewrite all your code. There where stupid limits like being able to wait for 1 semaphore at a time or something like that. And no filesystem support as well. Linux OTOH has always been the real deal on any platform which makes cross platform development using Linux so easy and productive.

Microsoft did have some early success in the mobile ARM space.

Not only with Windows CE but also with Windows Mobile/Smartphone. For a bit it did also support MIPS, but that was soon dropped and became ARM only. It was the dominant OS for PDAs and smartphones during about 2000 to 2010

Back then the first iPhone was not released yet and Android was not a thing yet. At that time it was an impressive feature for a phone to be able to play back a mp3 file. But Microsofts mobile OS could run native executables and had devices with reasonably powerful hardware. So it soon upped the party trick of a mp3 file onto being able to play most video files that PCs can play, open MS Office files, open desktop wepages (including javascript and flash), supported expandable memory, usb support, hardware accelerated graphics..etc. It had a lot of software ported over to it, game developers even ported entire PC games to it. Fair few companies now make Android phones(HTC, Samsung, LG, Sony) have started off making Windows Mobile devices (but then quickly jumped ship to Android due to Microsofts exorbitant licensing fees).

But then the iPhone and Android came around and made Windows Mobiles old simplistic UI look outdated (tho funny enough the Win10 UI now looks similar). So Microsoft came up with a 'brilliant' idea to redo the entire OS and rebrand it as "Windows Phone 7" we all know quickly that ship sank. It threw away all backwards compatibility in exchange for a modern UI and fitting into this Microsofts vision of unified UI across all there products, PC,Mobile,Gaming..etc

As an actual OS it had its good and bad sides. It was a sort of from the ground up imitation of PC Windows. It runs from a file system that you can freely access, it has similar folder structures (Windows, Program Files, My Documents). It runs *.exe executable and loads DLLs, it has a registry, the UI works similar to WinForms, it carries over DirectShow and DirectDraw APIs for hardware graphics and media. They really tried to pack as much Windows-ness into the couple of MB they had available. Later on it got .Net framework and this made the same EXE file run both on WindowsMobile or Windows XP, Keep in mind that years later the iPhone launched and it couldn't even do multitasking for years. But the OS did take shortcuts, memory protection was barely existent, it used persistant RAM as file storage (early versions only), native executables not only had to be compiled specifically for it, but also for the ARM or MIPS variant separately, it did need a reboot every few weeks.

Over all Windows CE/Mobile was a pretty good product given the time period and technical limitations. Just that Microsoft ended up running it into the ground with its aggressive business practices.

[brucehoult]

CISC or RISC is a property of instruction sets, not of CPUs.

This is being rather pedantic.

You mean "precise".  The ISA is the most important interface in a computer -- it is how the programmer speaks to and instructs the hardware.

It is perfectly valid to refer to a "RISC CPU", it means "a CPU that has a reduced instruction set.

Which still makes the instruction set primary.

By corollary , a "CISC CPU" is a CPU that has a CISC instruction set.

And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."

[David Hess]

And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."

Doesn't it?  CISC legacy instructions are translated into longer fixed width RISC instructions which are then reordered and dispatched into multiple (superscalar) pipelines.  That sure seems like RISC underneath.

Does your statement mean that RISC chips which support instruction compression are not RISC?  What about RISC chips which support instruction fusion?

[ejeffrey]

There is plenty of software out there that is still 32bit. The piece of software written to run on a 386 can still just simply be run natively from an executable file on the latest CPU that Intel and AMD makes.

Tho with how fast computers are getting it makes sense to instead emulate for backwards compatibility. But that work has to be put in by the OS developers like Microsoft, they wouldn't really get anything in return for that work, they would just make Intels life easier.

I don't think they are taking about removing the ability to run 32 bit code.  32 bit code is directly l supported in long mode.  As far as I can tell they are only talking about removing the non 64 bit operating modes of the CPU - real mode, 16 bit protected mode, 32 bit protected mode, and vm86, and booting directly to long mode.  It would only affect the boot sequence and the ability to run 16 and 32 but operating systems.

[brucehoult]

And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."

Doesn't it?  CISC legacy instructions are translated into longer fixed width RISC instructions which are then reordered and dispatched into multiple (superscalar) pipelines.  That sure seems like RISC underneath.

The µops that current x86 CPUs translate the original x86 code into are nothing like RISC. They are still, for example memory-register operations, not load/store and then register-to-register for arithmetic. For example, in Zen 1 to Zen 3, adding a register or constant to memory (a read-modify-write operation) is just 1 µop, though quite high 6-8 cycle latency. Very much a CISC implementation. On RISC it would be three instructions. On Intel since Core 2 it's 2 µops -- slightly broken down, but not RISC.

Does your statement mean that RISC chips which support instruction compression are not RISC?

What do you mean by compression? Two instruction lengths?

Almost all the early RISC ISAs had two instruction lengths:

- CDC6600: 15 and 30 bits

- Cray 1: 16 and 32 bits

- IBM 801: 16 and 32 bits

- Berkeley RISC II 16 and 32 bits (RISC I was a quick&dirty test chip that didn't work properly anyway)

It was only for about ten years from 1985-1995 that RISC ISAs had a single 32 bit instruction length.

Two lengths have been the norm both before and after that decade.

Hitachi Super-H started with 16-bit instructions only, then added 32 bit. Arm licensed Hitachi's patents for the Thumb 16 bit instructions, MIPS did MIPS16. RISC-V of course was designed from the outset to support both 16 and 32 bit instruction lengths.

The only RISC ISA since 1995 that hasn't had two instruction lengths is Aarch64. I was extremely surprised by this when I read the ISA manual in October 2012. It seemed like such a huge mistake after the great success of Thumb2, leading to poor code density. It seemed even more like a mistake after RISC-V appeared a few years later with two instruction lengths and much better code density.

What about RISC chips which support instruction fusion?

That is implementation, not ISA. RISC is about ISA.

[james_s]

CISC or RISC is a property of instruction sets, not of CPUs.

This is being rather pedantic.

You mean "precise".  The ISA is the most important interface in a computer -- it is how the programmer speaks to and instructs the hardware.

It is perfectly valid to refer to a "RISC CPU", it means "a CPU that has a reduced instruction set.

Which still makes the instruction set primary.

By corollary , a "CISC CPU" is a CPU that has a CISC instruction set.

And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."

I still say it's pedantic.

The whole RISC vs CISC thing is largely irrelevant today anyway. Traditionally CISC processors have adopted techniques pioneered by RISC processors, while RISC processors have become more complex. Where exactly is the boundary between RISC and CISC anymore? I don't think it's clear cut. Certainly not anything like it used to be. Most software developers today don't directly touch the hardware, they don't care about the instruction set. The entire platform my company builds is written in Python and Javascript.

[SiliconWizard]

The entire platform my company builds is written in Python and Javascript.

Condolences.

[brucehoult]

I still say it's pedantic.

Engineers are required to be pedantic, in order that bridges and planes don't fall down.

The whole RISC vs CISC thing is largely irrelevant today anyway. Traditionally CISC processors have adopted techniques pioneered by RISC processors, while RISC processors have become more complex. Where exactly is the boundary between RISC and CISC anymore? I don't think it's clear cut. Certainly not anything like it used to be.

Repetition is not proof.

Most software developers today don't directly touch the hardware, they don't care about the instruction set. The entire platform my company builds is written in Python and Javascript.

You're quite right that most developers, let alone users, don't have any reason to care about the instruction set, as long as their computer is fast enough.

That is why it doesn't matter that your opinions are wrong. You're not the one designing the bridges and planes.

It matters a lot to the people writing the JIT your Javascript requires to run at decent performance.

[David Hess]

You're quite right that most developers, let alone users, don't have any reason to care about the instruction set, as long as their computer is fast enough.

That is why it doesn't matter that your opinions are wrong. You're not the one designing the bridges and planes.

It matters a lot to the people writing the JIT your Javascript requires to run at decent performance.

Linus Torvalds has talked about that in the past.  The ironic thing is that some aspects of available RISC designs, like relaxed memory ordering and paging, make them *slower* than x86 in those sorts of applications.  Operating systems like MacOS have the same problems compared to Linux and sometimes even Windows.

The rare cases which RISC processors decline to handle can have large effects on performance in practical systems.  Some operations are just better handled in hardware.