andreiw

Not ARM64 ports. Important difference. But yes, you can go download an ISO now and boot on any ARM64 server. Cool stuff.

No, it wouldn't.

Sometimes I wonder if IA-64 was just an exercise in killing of Alpha and HP-PA...

Anyway, x64 succeeded because instead of producing something no one asked for, and poorly (IA-64), AMD went to Microsoft, found out what they wanted from a 64-bit chip, and built that.

Not true. When multiarch mattered (NT 3 and 4), Microsoft was the only vendor that delivered the exact same OS, device support and development environment across x86, Alpha, MIPS and PowerPC, and pushed the industry towards standardization. Microsoft has always taken arch and platform independence seriously, and this was evident even in 2010 when I worked on NT. You could rebuild the whole system for any supported arch (x86, x64, ia64 when that mattered), now arm and arm64

It's funny, but Microsoft was spot on correct to continue supporting 32-bit x86 on par with x64. Now they can just support BTing 32 x86 on ARM64 instead of being forced to support 64-on-64, which would simply involve more overhead.

And yet the Snapdragon has nothing to do with any shipped or to be shipped ARM server parts...

The ARM server chips are not related to their mobile counterparts. Pretty much everyone is doing a custom microarchitecture, instead of growing mobile designs or building on ARM's own IP.

The 2017 chips (3rd generation) are Xeon E5 competitive.

Which chips are you refering to, specifically? Because otherwise it's a blanket statement that is simply untrue.

Actually, the only signal so far is to AMD to continue investing developing ARM chips after the A1100.

No, this is the real deal, apparently. Obviously the work has gone on for years but between OCP and Xeon competitive chips (ThunderX2 and Centriq) it makes sense to put public weight behind it.

The real question is if WSL (Ubuntu for Windows) will be available for AArch64 Windows. Because the only real 64-bit ARM software ecosystem today is Linux (courtesy of Linaro, Redhat, Canonical, Suse, and ARM).

Between WSL and BTing legacy 32-bit x86 apps this could be a decent offering for folks who already have Microsoft infrastructure. Even cooler if Hyper-V is ported.

Time and time? We do see them in Linux.

The ARM server ecosystem has been in the works for a few years. TechCon'16 we saw the announcement that the software is fully there: and this is not hype, all major distributions support all the major players out of the box. Download ISO, install, and use it.

HW-wise we are now in the 3rd gen of chips (QC Centriq, XGene3, ThunderX2) all of which compare with E5, not Atoms. First/Second gen were mostly proving grounds for the specs and software work, excepting for Cavium machines, which have some serious network I/O where the relative wimpyness of any one of the 96 cores simply doesn't matter for certain workloads. In a matter of two years we've seen private datacenters soak up XGene2 and Cavium chips. We've seen ODMs and OEMs get their shit together and start selling real kit (b2b.gigabyte.com).

It's funny, people expect these things to suddenly appear overnight everywhere and competitive with E7s and Power9. It takes decades, but the server guys managed to fit in nicely in about 5 years. I am excited.

The government should do my taxes. No, seriously. They already know enough to figure out if I made mistakes in my tax return, so there's no real utility here, beyond giving every tax payer the ammunition to land themselves in hot water.

There's no real reason why every year everyone needs to go through this pain behind the eyes. And letting accountants do it doesn't really lower the stress level - I still need to hand off all the "state" and paperwork necessary, and I'm still on the hook if the accountant gets it wrong (I've had this happen to me, too, and it's not fun). Doing taxes is not productive.

So ARMv7-A is still, like, a thing?

non-volatile memory tech, e.g. NVDIMM

This is an important realization and will become even more so as we transition toward NVM.

I hit this realization partially about 7 years ago developing a custom loopback disk driver, capable of handling different image formats. I'd have all these great ideas about caching metadata, but actual measurements would reveal worse performance than seen with just always going straight to the block interface.

Toxic behavior 101. One dude, who I am sure most people never heard of, spouted off about some demo code written decades ago by a guy that is the quintessential successful software engineer and that everyone knows about, probably even little kids in remote villages with no electricity. Now other dudes feel necessary to conform. Riling on about Bill's purported technical ineptitude doesn't put him down, or put you up anywhere near his level - it just makes you look like a donkey. This is intellectual dwarfism. Don't do it, because it's your own little glass ceiling (same goes for spreading the 640k rumor). It also looks lame and unprofessional, and we work in a pretty small industry, in terms of the kinds of people most of us would work around anyway.

And yeah, billg is the quintessential successful "startupper". Yes, he came from a priviledged background. Yes, he had some wonderful partners and colleagues, and yes he had the priviledge to have access to real computers at a tender age. All of this is really pretty typical of american enterpreneurship in a new hot market. And none of this takes away from Bill's own software engineering background and acumen. Remember: he developed and sold real products without finishing college. He started an extremely successful software company, successful in a large part because of Bill's extreme demands for technical and business excellence. He also knew when to move on to create a real difference elsewhere via the Gates Foundation, and doesn't live like the Kardashians or John McCaffee. He is a humble, very learned and hard working guy that all of us have plenty to learn from.

I tried to look something up but there is no mention of underlying tech... is this at all related to PTP?

- Going with the gut instead of listening to others. I had the surrealistic experience of a bunch of extremely senior folks around a company telling me not to join a team I had done a project for. I should have listened, esp. in light of the fact that the folks advising were not only not from the same team, but in many cases actively disliked each other (i.e. this was not a conspiracy).

- Ignoring the office politics. I thought, naively, that doing above and beyond technically and being frank about situations around me would get me somewhere. It turned out that someone I had put in a not-so-favorable crosshair, while describing my fairly significant cross-team collab efforts, was chummy with my manager's manager, and it blew up in my face... see next item...

- I had the misfortune of deciding to report to an average-engineer-turned-mediocre-manager. Typical deer-in-headlights-look turnstile manager - i.e. the kind that takes plenty of credit, but doesn't shield you from anything. The guy was laughably terrible, because it was extremely obvious when he was trying to screw you in 1:1s. I was young and stupid and it ended pretty nasty: vindicative passive-agressive bullshit, blame game and damaging rumors that impacted my professional relationship with the rest of my ex-teammates.

- Not setting priorities straight. I had a personal situation that involved a lot of travel. It didn't even matter that I was exceeding expectations - visibly, I was never there, and that is all that ultimately mattered.

But these are all symptoms! The biggest mistake was not identifying a mentor. Not a technical mentor, but someone seasoned, high enough in the social ranking, and vibrant enough (i.e. not semi-retired and clinging to the job) to advise, help and teach how to navigate a large megacorp with its feudal cliques, ol' boy's club politics and Machiavellian egoes.

Does anyone know if the GPU can then be passed thru to VBox or Fusion?

Now rewrite in IR =))

Not really. IR is exactly a good fit for compiled languages, because there are no "hard to translate" idioms in languages targetted by LLVM that need really orthogonal translations on different architectures, which by the way aren't really all that different at a high level.

However I am still looking for a use case to write IR directly, or in place of bits of inline assembly.

That's all fair and correct, but the amount written for, say, an OS, in assembly - native or IR - is quite minimal and well-controlled, usually written in assembly because of a good reason (exception handlers, for example). At that point, it's just more obvious to write in native assembly, given that you're writing architectural code, and for a different architecture, that code would be sufficiently different.

So again, I see all the value in IR for compilers. Can someone give me at least a reasonable use case for beginning to write in IR, or even using IR for optimizing cerain code paths?

The other thought I had here, is that AFAICT IR is not a standard. There is no requirement that it remains compatible in 50 years or 5 months. There is no standard IR, and shouldn't be, as that would become an impediment to compiler evolution and fit/optimization to newer architectures.

Doesn't AS/400 use an IR approach as well? Which let IBM seamlessly migrate the underlying CPU a few(?) times now?

In this way, IR would fullfil the same role Macro-32/64 did for porting VMS to Alpha and beyond. However, it appears to my understanding (sorry, I was still crawling when VAXes were on the way out), that the benefit was retaining "VAX" syntax to avoid massive rewrites.

If you're starting from a clean slate, what's the benefit of writing IR? Why not use C? After all, IR won't really give you complete control over generated code, and it's still an abstract VM (albeit that obviously allows writing IR that will only sensibly compile on a specific arch - e.g. system register acceses and so on).

Yeah, I think something like dlopen/dlsym, but stand-alone, and supporting ELF/PE32+/Mach-O binaries (both objects and binaries, shared objects, PIC and non-PIE) on any OS/architecture could be very useful. Even foreign support (i.e. load x86 obj on MIPS), as it could be used by emulation engines.

wat? v8.2 is out and soon in products, v8.3 has been announced. What do you consider to be very complex, if you throw away 32-bit support? What specifically do you consider to be "screwed up", beyond the virt hole with cntfrq_el0, which affects migration between different vendor implementations? The whole VHE affair is more about enabling specific design decisions made by the AArch64 Linux implementation, if that's what you're alluding to. Certainly an ARMv8 implementation without VHE is not broken, virtualization works just fine.

FWIW 64-bit ARMv8 is clean as well, designed without all the weird baggage that came with the 26->32 legacy ARM architecture. More importantly, ARM had reduced the impedance mismatch with x64, making porting various kinds of software (including system and virt) to ARM64 a relatively trivial affair. IBM seemed to have taken a few cues from that, finally implementing similar MMU and MMU virt support in Power ISA 3.0 (Power9).

Except it is not the MS-DOS prompt (unless you actually ran command.com, via the NTVDM). It may look like a duck, quack like a duck (sort of), but it really was just another Win32 (albeit console) program.

You know what I just realized? Apple could have made the power port simply be recessed a bit...that way you could either plug in a USB-C device or a cable like this and not wind up with a wart (that the laptop can still fall on and thus break the actual USB-C solder points)

That might be the entire mobile ecosystem (although that sounds too simplistic, still, you are forgetting Linaro), but the ARM ecosystem also includes M-profile (deep embedded), R-profile (RTOS) and server-class (SBSA and "almost" designs like Octeon-TX and Tegra X1). The ARM server ecosystem is most definitely a bunch of software and hardware players, and Google is not a significant presence there FWIW.

Why only 2GB? Especially for a device that's not shipping yet. I understand there might be SoC limitations, but I would be really surprised if the A64 cannot support 3 or 4GB.

A53 is a bit on the slow side, but the worst part is that it's not a great (as in, representative of the architectural requirements on software) chip for porting software to AArch64, because of its simplistic design - you will be able to get away with forgetting a barrier, or TLB or cache maintenance instruction here or there, and your code will work (but blow up on other, more advanced uarches, like A57 or other non-ARM designs). It's basically a minor step above using Foundation Model.

And yet a weaker memory model (as well as explicit cache and TLB maintenance) remove a major glass ceiling from both theoretical chip performance, practical perf/watt and silicon design and manufacure costs.