andreiw

OSS (FOSS/FLOSS) and the current push to boutique vertical software stacks largely make ISA wars irrelevant. Right now if it runs Linux and does virtualization it is good enough, and organizations will buy gear based on other characteristics. And Microsoft realized they don't want to be a purveyor of x86 goods either, probably because they don't want Windows to turn into another OpenVMS or AIX.

Intel manufacured 32-bit ARMv5 chips via a unit originally acquired from DEC in '97. It was sold to Marvell 10 years ago. It's hard to see how any of this would help Intel create competitive ARMv8 server-class chips, but you're right, given their market hold of their x86 chips they clearly have the means to do it. However it would probably take a significant amount of time, and they would have real competition. Sadly, I don't think they'll be investing into server-class 64-bit ARMv8 chips, and that's a mistake. CPUs are a commodity now, and the architecture wars are largely irrelevant with a heavy push towards OSS stacks. It's a race to the bottom, and ARM chips are going to be simpler for the same amount of performance, and that means ultimately cheaper.

I'd say that even two years ago most mobile phones being sold were already ARMv8. That doesn't help with the SoC documentation, you're right that this has been a consistent weak spot. Usually documentation is offered up or it washes up only when the market relevancy of any one SoC approaches zero. Before then, it's passworded up and jealously guarded. Makes no sense to me, especially when you consider most of any one SoC to be consisting of reused generic IP blocks. I mean, I can deal with an NDA for something tricky like your new GPU, but that doesn't explain why I can't figure out the interrupt routing or your clock and GPIO blocks.

If you're referring to ARM servers, then things are still pretty solid (it takes a while to line up an entire hardware and software ecosystem, even in a world where you're all set if it runs Linux). There are specs like SBSA and SBBR that ensure servers from any SoC vendor look roughly the same, but I would wonder why you would target bare metal in that case anyway. Have you considered targeting ARMv8 VMs, like the one modeled by KVM/qemu? Extra bonus in that it looks like an ARM server.

Nothing is ever so simple, and I agree wih you that the sensationalism that pairs with schizo tech journalism, that seems to dash from one extreme to the next, is pretty tiring, with media analysts frequently glossing over important details that don't fit their current world view.

However, mobile devices are the same kind of disruption to PCs as the later were to the UNIX workstations and servers of yore. Intel missed that transition and failed to see the threat. They've tried in early 2010 to establish any x86 Android presence but it didn't work out. Funny, but things might have been different if XScale wasn't sold off, who knows...mobile/handheld mostly stagnated back when it was WinCE/Palm, even though Palm invented the HPC and Microsoft practically invented the smartphone.

IoT/IoE is another major disruptor, on many fronts, and Intel doesn't seem to get it. NFV is probably going to converge on ARM64, due to the "good enough" factor, TCO, specialized I/O accelerators, cheap customized server SoCs and cutthroat competition. Windows on ARM64 opens up VDI opportunities, as does the proliferation of "smart" Android-powered devices. Open source ended being the Colt of the computing world (Chip vendors create computers but Linux made them equal), so in the cloud, architecture is irrelevant, only the bottom line...it's a race to the bottom and we all get to win, but Intel might not make it.

Great. When will this target ARMv8 64-bit 'A' profile chips?

So how come this throttling doesn't affect Airs that didn't encounter water bottles? What am I missing?

Well, that just about says everything you need to know about her tenure, more or less. There's no real reason she couldn't have influenced Yahoo's offering to improve in that direction, if it were that important.

Really cool. So if there 3 separate instances running, how do they stay in sync? Surely these 18 bytes are not everything? So you feed the same input to all 3 instances at the same emulated time?

So destroying America's manufacturing potential in everything from textiles, to electronics and heavy industries was all part of a scorched-earth secretive plan to fight Communism in China?

I dunno. Reading this article left a bad taste in my mouth. It wasn't the Chinese that turned a large portion of industrial America into a rusty meth-infused wasteland, yet it is the Chinese that are opening these factories. I applaud a desire to maintain safety standards, but if it wasn't for Fuyao, there wouldn't be anyone to unionize, you know?

UEFI? SBSA compliance?

It's a plausibly-deniable backdoor on top of LD_LIBRARY_PATH, just to clarify. As in - oops, I added the colon at the end, or if the LD_LIBRARY_PATH was programmatically generated, a sloppy loop can clearly do that...and now you're stuck with unexpected behavior which, while not directly unsafe, can be coopted in a nefarious manner. The $PWD behavior is niche, unexpected and likely to be missed in an audit. If you have software that relies of LD_LIBRARY_PATH and you distribute the OS, I'd change ld.so to avoid the $PWD behavior.

Of course, it will stay locked for a few. Is the IBM/COBOL crowd representative of today's compute resources? Not really. The same could be said about OS/2-powered ATMs and point of sale terminals. The fact of their continued existence doesn't prove the OS/2 is a widely deployed and growing technology.

But overall, the world has changed quite a bit. We're suddenly not in a world ruled entirely by DB2, MSSQL and Oracle, running on AIX, Windows and Solaris. The software stack has opened up, and is no longer bound to any specific platform. The few big software names don't get to decide what kit to run them all...we're approaching a world where ISA won't matter. You'll buy hardware because it fits your performance and TCO targets, not because you're locked in.

What sucks for Intel is that they've failed to identify mobile devices as the "next PC", in the sense of the disruptive potential...the PC killed boutique workstations and servers and it killed them from the bottom. Along with IoT, that's two huge opportunities missed. Itanium was a pincer attempt, but no one targets the top and succeeds... you have to start at the bottom (this is btw why Power needs to scale and price down if it hopes to grow beyond its niche).

For one, it makes legacy x86 support in the upcoming ARM64 Windows SKU that much simpler and lighter weight, since there's less stuff to support (and a smaller address space to virtualize). Since every bit of software, in practice, already has to be 32 and 64-bit, MS can focus on 32-bit x86 emu alone for compat, and let vendors ship ARM64 binaries if required.

Thing is, that's slice of computing that gets progressively smaller, and both the upcoming Win10 on ARM64 laptop devices (with the BT for x86) and E5-competitive servers with Windows will take care of this enterprise segment.

But that's hardly really true anymore.

A 64-bit x86 computer with UEFI and wihout a CSM, for example, has no way to boot DOS or even a 32-bit OS (which could then use v86) to support the really old legacy. You'd have to resort to using a hypervisor, but considering the practical difference in performance, you could do the dumbest possible emulation and still run those 16-bit tasks just fine.

But that's just details. For the massive scale-out farms that power today's world with solutions based on OSS components, running proprietary legacy code just doesn't matter, so the backwards compatibility is irrelevant.

Man, whoever wrote this is tone-deaf...does Intel even understand, that barriers to emulating x86 might have worked in 90s and the aughts, but that it is completely irrelevant now? Does Intel understand, that considering the penetration of OSS in the cloud and enterprise data centers, the ISA just doesn't matter anymore? They have a competitive CPU implementation, but mostly in spite of the front-facing instruction set, certainly not because of...

you know, that's a pretty good plausibly-deniable backdoor, if you think about it...

sounds like a pretty good thing to disable in ld.so...

I think in this case this is mostly having access to the right specs, and preferrably having spent time working on the controller firmware...

Cool. Where's the ARM64 linux build? That's more important than the legacy 32-bit ARM builds (i.e. ARM servers)

Wait, so the Go assembler allows generating invalid opcodes?

Any way of using a more normal assembler with a non-GNU Go compiler?

I spent a minute looking at this and I still don't understand what is being offered.

Is it a bluetooth HID device to pair to an emulator app? Is it an actual Z80-based system? Why is it called a ZX Spectrum? Because it looks like one?

I miss my Russian ZX80 clones. One stayed pretty true to the original format, the other one was a whopping desktop AT case with two 5 1/2" drives. Both, ultimately, were plagued by soldering quality issues, given their back-of-the-garage heritage.

Where's the ARM64 port going? I see that it's been stalled for a few years.

One thing that stands out over almost every other similar article is that there are alternative calling conventions available. That is - awesome. Not sure if this is something easily defined in a crate, or if it is intrinsic, but it is very liberating to know that you don't need to craft exception entry / exit code unless you really want to. That makes OS-level tinkering much much more approachable.

Seems to work well for me. I wish the routers themselves were a bit more rectangular (the height is a problem for fitting in certain spaces, and it's not very stable due to its narrow base). The dedicated back haul between satellite and main router works as advertised. A bit pricy, but oh well.

Not that odd. The NT group specifically wanted a portable design, and they made the right call to initially target i860, MIPS and only then i386 machines. Contrast that to OS/2 development - the (never shipped) PowerPC OS/2 port was based on top of of an IBM fork of Mach, because the kernel was too x86 specific (derived from the pre-virtual memory 16-bit protected mode code).

Binary translation / JIT. Like Apple did with Rosetta or like DEC did on Alpha NT with FX!32.

We're talking complete hypotethicals. When x64 was introduced, not only weren't there any consumer Itanium chips, but they weren't even hypothetical.

For servers - yes. And not just the 64-bit ISA, but the server specs/standards, the hardware ecosystem, OEM/ODM engagement...and software, of course! And conjecture - in the cloud it won't matter what arch you are on.

If you were talking about the mobile 32-bit world, you would be correct.

The 64-bit world is very different. It is very homogeneous, it looks like an x64 server basically. Userspace actually wasn't ported that long ago. Fortunately now all the major Linux players fully support ARM64 servers (you can download an ISO and install on any ARM64 server without any voodoo, just like x64).