OSDev.org

Does anyone know about this?
http://www.extremetech.com/computing/18 ... -same-chip
http://wccftech.com/amd-developing-gene ... a-support/

Article wrote:This article is speculative — AMD has not acknowledged such a strategy at this point — but if you read between the lines a bit, the pattern fits. Making the Puma+ and ARM SoC’s pin-compatible next year means that the two chips will use a common memory controller, PCI-Express interface, and cache structure. They’ll standardize on the same HSA implementation, and they’ll have the same I/O standards. It’s a first step — but just a first step.

Looks like a solution in search of a problem.

Bender wrote:Does anyone know about this?

AMD just must to try something extravagant to get some competitive advantages. Because it is unable to beat Intel on it's field. My humble recommendation to AMD is to get interested in compiler centric approach, when processor's architecture is designed to match compiler's needs. Such approach is closer to the AMD's powerful positions like GPU design, and more general - parallel processing and compilers for such an area (like GLSL compiler).

Hi,

Remember when Intel decided they'd use the same socket for both Itanium and 80x86? It made perfect sense at the time (as a way to reduce the cost of designing chipsets, etc). There were even a few people hoping to see Itanium and 80x86 chips in the same computer. Of course in Intel's case it didn't actually happen for a variety of reasons.

This sounds exactly the same to me - e.g. AMD wanting to use the same chipsets, etc for both 80x86 and ARM to reduce costs. The only difference is that instead of "a few people hoping" there's actual unsubstantiated hype involved.


Cheers,

Brendan

This does seem to imply we'll see PC-like ARM machines (using a PCI bus, standard *HCI USB, AHCI SATA, uEFI, PC network chipsets), which would be awesome for getting more hobby OSes ported to ARM.

I like this idea

(disclaimer: I haven't read much from the linked article, just interpering Brendan's comment)

thepowersgang wrote:This does seem to imply we'll see PC-like ARM machines (using a PCI bus, standard *HCI USB, AHCI SATA, uEFI, PC network chipsets), which would be awesome for getting more hobby OSes ported to ARM.

To have such PC-like machines we need an instruction set independent OS.

Which doesn't seem that possible as of now... (at least as far as I know). Especially if you are gonna have most (or all) of your code compiled. Unless you are willing to do something similar to what Java does, you have the code compiled to a bytecode and the interpreter is the only part you will have to change for each instruction set (still not completely instruction set independent, also the word interpreter might suggest you have a drop in performance, but if portability is that important I guess this makes it much easier.)

embryo wrote:To have such PC-like machines we need an instruction set independent OS.

Why that? An OS that runs on a PC-like platform with ARM doesn't have to run on anything else than ARM. The nice thing about having this platform for porting your OS wouldn't be about the CPU, but about most of the other standard hardware.

hometue wrote:Which doesn't seem that possible as of now... (at least as far as I know).

It is possible

Kevin wrote:

embryo wrote:To have such PC-like machines we need an instruction set independent OS.

Why that? An OS that runs on a PC-like platform with ARM doesn't have to run on anything else than ARM.

If there are no "PC-like" software, then why to keep all the "PCI bus, standard *HCI USB, AHCI SATA, uEFI, PC network chipsets"? Why not to introduce something new?

Hi,

embryo wrote:If there are no "PC-like" software, then why to keep all the "PCI bus, standard *HCI USB, AHCI SATA, uEFI, PC network chipsets"? Why not to introduce something new?

Cost.

An "ARM system" is currently one of several (related but incompatible) CPU cores, slapped onto "who knows what" as a chipset, with no standard/s for firmware/preboot at all and no sane way of doing basic things (like detecting what hardware is present rather than hard-coding). This is fine for embedded systems. For things like servers it's a disaster.

For a server you want an actual architecture with actual standards; so you can have a "generic ARM" OS that (e.g.) comes on an installation CD and uses (e.g.) things like UEFI, ACPI and PCI to detect what hardware is present, which drivers to install, etc.

For AMD to produce viable ARM servers, they need an actual standard architecture (not just CPU, but the rest of the hardware and firmware) plus OS/s that will run on it. They have 2 choices...

They can create some sort of committee to design a new standard architecture (several years); then design, create and test/validate new hardware/chipsets for the new standard architecture (several more years); then create new firmware (several more years) and hope someone wants to port/create an OS (several more years). All of this takes time (e.g. I'd guess 10 years before it'd be a viable alternative to 80x86); and while all of this is happening Intel will continue to do whatever they can to destroy any hope AMD have of getting ARM servers into the market.

The alternative is to take an existing architecture like 80x86 (including UEFI, ACPI, etc) and use existing chipsets. That way they can start with a motherboard designed for 80x86 Opteron, slap an "ARM Opteron" chip in it and change the firmware (from 80x86 UEFI to ARM UEFI). It's a lot cheaper to do, and gives a far more viable "time to market". From what I've heard, this is also exactly what AMD is doing.


Cheers,

Brendan

You don't need an instruction set independent OS to run on an ARM core, with or without PCI (which many ARM platforms already use), USB (which most ARM devices already support), SATA or PC network chips (which off the top of my head at least ARM Chromebooks already use), or UEFI (although it might be nicer to use something like coreboot/Das U-Boot, as UEFI is a monstrosity and coreboot seems to already support ARM specifically for those Chromebooks).

You don't even need one to run on a dual x86/ARM system if you're willing to have separate binaries for the two cores. You don't need anything higher level than C in order to be to be instruction set independent either- you don't need an interpreter, you don't need a JIT, you don't need worthless, leaky abstractions in your language, you just need install-time or maybe first-run-time specialization to one instruction set or the other.

Brendan wrote:

embryo wrote:If there are no "PC-like" software, then why to keep all the "PCI bus, standard *HCI USB, AHCI SATA, uEFI, PC network chipsets"? Why not to introduce something new?

Cost.

May be. It is not an absolute winner every time, but cost is very important factor.

Brendan wrote:For AMD to produce viable ARM servers, they need an actual standard architecture (not just CPU, but the rest of the hardware and firmware) plus OS/s that will run on it. They have 2 choices...

They can create some sort of committee to design a new standard architecture (several years); then design, create and test/validate new hardware/chipsets for the new standard architecture (several more years); then create new firmware (several more years) and hope someone wants to port/create an OS (several more years). All of this takes time (e.g. I'd guess 10 years before it'd be a viable alternative to 80x86); and while all of this is happening Intel will continue to do whatever they can to destroy any hope AMD have of getting ARM servers into the market.

In case of Android there was no such time (like 10 years). And costs were not the main problem. It means there is another option.

Brendan wrote:The alternative is to take an existing architecture like 80x86 (including UEFI, ACPI, etc) and use existing chipsets. That way they can start with a motherboard designed for 80x86 Opteron, slap an "ARM Opteron" chip in it and change the firmware (from 80x86 UEFI to ARM UEFI). It's a lot cheaper to do, and gives a far more viable "time to market". From what I've heard, this is also exactly what AMD is doing.

But what about software? What OS will run such server? Things like endianness can prevent plain recompilation of Linux's drivers for x86 environment, it also matters for another software. But I have no experience with such a great recompilation and can't see potential problems.

Rusky wrote:You don't need ... you just need install-time or maybe first-run-time specialization to one instruction set or the other.

If things were such simple - why we still have no viable alternative to the Intel's x86?

embryo wrote:

Rusky wrote:You don't need ... you just need install-time or maybe first-run-time specialization to one instruction set or the other.

If things were such simple - why we still have no viable alternative to the Intel's x86?

Eh? Just by looking at sales alone we see that plenty of system designers see ARM as an alternative to the x86 architecture.
The following report shows about 28% non-x86 MPU sales:
http://www.icinsights.com/news/bulletin ... U-Ranking/
Is it accurate? I don't know but I'm using it anyway There's plenty of alternatives to x86 and in certain application areas you just don't see x86.

embryo wrote: In case of Android there was no such time (like 10 years). And costs were not the main problem.

Android has nothing to do with systems development and its development costs shouldn't be seen in that context (or at least not placed in comparison with other OS development costs and constraints). Android is part of a bigger picture put in place by a company that sells advertising.