Products > Computers

Intel considering making new CPUs 64 bit only

<< < (11/12) > >>

Berni:

--- Quote from: nctnico on May 24, 2023, 08:27:40 pm ---
--- Quote from: james_s on May 24, 2023, 07:07:14 pm ---
--- Quote from: Berni on May 23, 2023, 05:18:56 am ---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.

--- End quote ---

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.

--- End quote ---
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.

--- End quote ---

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:

--- Quote from: james_s on May 25, 2023, 05:54:44 am ---
--- Quote from: brucehoult on May 25, 2023, 01:52:59 am ---CISC or RISC is a property of instruction sets, not of CPUs.

--- End quote ---

This is being rather pedantic.

--- End quote ---

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


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

--- End quote ---

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:

--- Quote from: brucehoult on May 25, 2023, 07:49:31 am ---And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."
--- End quote ---

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:

--- Quote from: Berni on May 22, 2023, 05:35:52 am ---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.

--- End quote ---

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:

--- Quote from: David Hess on May 25, 2023, 05:01:45 pm ---
--- Quote from: brucehoult on May 25, 2023, 07:49:31 am ---And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."
--- End quote ---

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.

--- End quote ---

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.


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

--- End quote ---

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.



--- Quote ---What about RISC chips which support instruction fusion?

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod