Apple Seeds Third macOS Sierra 10.12.1 Beta to Developers

[cube]

No problem

You could emulate x86 code, but it's so complex that anyone who seriously tried, failed.
In addition x86 is a CISC architecture vs ARM is RISC, (x86 can execute more complex machine instructions and is not limited to one instruction per clock cycle), which would result in x86 code being emulated on ARM to take about 50% hit compared to native execution, which is huge.

Out of curiosity, what makes you so excited about ARM in the MacBook?
I fail to see any obvious benefits apart from battery life, where Intel is catching up faster than ARM is in terms of performance.

ARM has out of order execution since Cortex-A9.

But it is true you don't want to emulate x86 on ARM.
[doublepost=1475519822][/doublepost]

RE : ARM.

Possibly coming is ARM in new MacBook Air.
Or ARM in new ACD.

Or macOS X on iPad Pro.

 

[MacHiavelli]

ARM...

 

[Peace]

ARM has out of order execution since Cortex-A9.

But it is true you don't want to emulate x86 on ARM.
[doublepost=1475519822][/doublepost]
Or macOS X on iPad Pro.

I was thinking that too. It's easy to change a header file.

Or a Mini/Apple TV.

 

[jasonklee]

I guess I got a little blind-sighted by the ludicrously powerful benchmark results of the iPhone 7. How much of that can be comparable due to the OS is up for debate, however it's difficult to argue that they're stunningly good for something with no cooling, that you hold in your hand. I wonder whether a larger chip with cooling could really stick it to Intel.

I'm mainly excited about the prospect because it is, to me, the culmination of Jobs' vision. It's what Apple is, at its core (pardon the pun). Apple software running on Apple hardware. In-house design and optimisation. A hardware pipeline completely in Apple's control. Seamless hardware and software. Computers which are screamingly good. A Mac that is... a Mac.

I guess I must be sounding a little misty-eyed about what CPU goes into a computer.

Apple taking larger responsibility over the fundamental design of their products always seems like a plus for me. Baby steps. A MacBook with a Ax chip? Sign me up.

 

[mildocjr]

Wow! Do you see the 'c' letter? That means there were TWO respins of this beta build. I'd hazard a guess that this might be the final beta build of 10.12.1...

I was thinking it was for the MacBook Pro c, it's essentially the 2013 MacBook Pro with a brightly colored plastic cover.

 

[cube]

I was thinking that too. It's easy to change a header file.

Or a Mini/Apple TV.

Think about it:

- An ARM MacBook Air removes functionality
- A macOS X iPad adds functionality
- Now you see a reason to change M for m
- What's Pro about the smaller iPad Pro's?
- Apple needs to catch up with Microsoft

On the other hand Apple is known for removing functionality.

 

[Peace]

Think about it:

- An ARM MacBook Air removes functionality
- A macOS X iPad adds functionality
- Now you see a reason to change M for m
- What's Pro about the smaller iPad Pro's?
- Apple needs to catch up with Microsoft

On the other hand Apple is known for removing functionality.

How does an ARM MBA remove functionality ?

 

[xflashx]

I hope that these rumors of using ARM Chips are not true... as soon as this happens I'm out and have to switch back to windows. There are several good reasons why Windows RT (Windows for ARM processors) is dead. No one wanted it and there were almost no apps/programs for it.
Im using a lot of programs which aren't made by Apple (for example MATLAB, Photoshop, R, Mathematica, SPSS) and I won't buy a PRO Device which runs a processor that has to emulate a x86 processor which will decrease performance significantly. ARM belongs to mobile devices, x86 to "the worlds most advanced operating system" as Apple describes macOS. Sure, if you are using a mac just for browsing and are using only Apples own apps you won't notice a difference. But those people can use an iPad. I don't want a "dumbed down" or limited operating system on a "real" computer. Even Microsoft gave up on their Surface RT, how can Apple even consider this? Let's all pray that those rumors aren't true, otherwise the Mac and macOS will die
[doublepost=1475522321][/doublepost]

How does an ARM MBA remove functionality ?

You can't execute programs (besides the programs by Apple) at all or (if a x86 processor is being simulated) just with a significantly high impact on performance.

 

[justperry]

If you do, please let me know! I'm convinced it's genuine as others have reported it too. However I'm dumb as a stump when it comes to this sort of thing, so I can't personally verify.

Regardless, I'm so excited.

For now I found this in :
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/mach/machine.h

#define CPUFAMILY_UNKNOWN 0
#define CPUFAMILY_POWERPC_G3 0xcee41549
#define CPUFAMILY_POWERPC_G4 0x77c184ae
#define CPUFAMILY_POWERPC_G5 0xed76d8aa
#define CPUFAMILY_INTEL_6_13 0xaa33392b
#define CPUFAMILY_INTEL_PENRYN 0x78ea4fbc
#define CPUFAMILY_INTEL_NEHALEM 0x6b5a4cd2
#define CPUFAMILY_INTEL_WESTMERE 0x573b5eec
#define CPUFAMILY_INTEL_SANDYBRIDGE 0x5490b78c
#define CPUFAMILY_INTEL_IVYBRIDGE 0x1f65e835
#define CPUFAMILY_INTEL_HASWELL 0x10b282dc
#define CPUFAMILY_INTEL_BROADWELL 0x582ed09c
#define CPUFAMILY_INTEL_SKYLAKE 0x37fc219f
#define CPUFAMILY_ARM_9 0xe73283ae
#define CPUFAMILY_ARM_11 0x8ff620d8
#define CPUFAMILY_ARM_XSCALE 0x53b005f5
#define CPUFAMILY_ARM_12 0xbd1b0ae9
#define CPUFAMILY_ARM_13 0x0cc90e64
#define CPUFAMILY_ARM_14 0x96077ef1
#define CPUFAMILY_ARM_15 0xa8511bca
#define CPUFAMILY_ARM_SWIFT 0x1e2d6381
#define CPUFAMILY_ARM_CYCLONE 0x37a09642
#define CPUFAMILY_ARM_TYPHOON 0x2c91a47e
#define CPUFAMILY_ARM_TWISTER 0x92fb37c8
#define CPUFAMILY_ARM_HURRICANE 0x67ceee93

I am less excited for now since there are also other ARM chips here and they won't be used in MacOS.
Something is fishy here.

And what about MacOSX10.12, shouldn't that be MacOs10.12

 

[MacHiavelli]

https://developer.apple.com/library...al/APIDiffsMacOS10_12/Objective-C/Kernel.html

Search for hurricane...

 

[keysofanxiety]

For now I found this in :
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX10.12.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/mach/machine.h

#define CPUFAMILY_UNKNOWN 0
#define CPUFAMILY_POWERPC_G3 0xcee41549
#define CPUFAMILY_POWERPC_G4 0x77c184ae
#define CPUFAMILY_POWERPC_G5 0xed76d8aa
#define CPUFAMILY_INTEL_6_13 0xaa33392b
#define CPUFAMILY_INTEL_PENRYN 0x78ea4fbc
#define CPUFAMILY_INTEL_NEHALEM 0x6b5a4cd2
#define CPUFAMILY_INTEL_WESTMERE 0x573b5eec
#define CPUFAMILY_INTEL_SANDYBRIDGE 0x5490b78c
#define CPUFAMILY_INTEL_IVYBRIDGE 0x1f65e835
#define CPUFAMILY_INTEL_HASWELL 0x10b282dc
#define CPUFAMILY_INTEL_BROADWELL 0x582ed09c
#define CPUFAMILY_INTEL_SKYLAKE 0x37fc219f
#define CPUFAMILY_ARM_9 0xe73283ae
#define CPUFAMILY_ARM_11 0x8ff620d8
#define CPUFAMILY_ARM_XSCALE 0x53b005f5
#define CPUFAMILY_ARM_12 0xbd1b0ae9
#define CPUFAMILY_ARM_13 0x0cc90e64
#define CPUFAMILY_ARM_14 0x96077ef1
#define CPUFAMILY_ARM_15 0xa8511bca
#define CPUFAMILY_ARM_SWIFT 0x1e2d6381
#define CPUFAMILY_ARM_CYCLONE 0x37a09642
#define CPUFAMILY_ARM_TYPHOON 0x2c91a47e
#define CPUFAMILY_ARM_TWISTER 0x92fb37c8
#define CPUFAMILY_ARM_HURRICANE 0x67ceee93

I am less excited for now since there are also other ARM chips here and they won't be used in MacOS.
Something is fishy here.

And what about MacOSX10.12, shouldn't that be MacOs10.12

You may have to bear with my utter ignorance, as I've got a load of questions! I know these will seem stupid... so thank you in advance if you'd be patient enough to answer.

1) Could the other mentions to ARM be systems already tested on earlier chips?

2) What's with the mention to PPC? Just CPUs that aren't supported any more? And if so, why are they there?

3) What does all that 0x000 stuff refer to?

Basically I'm not sure how to 'read' what you've written — what the relevance of each line is and what to look out for. Sorry again for my ignorance. But I'd rather look stupid now and learn something!

 

[justperry]

You may have to bear with my utter ignorance, as I've got a load of questions! I know these will seem stupid... so thank you in advance if you'd be patient enough to answer.

1) Could the other mentions to ARM be systems already tested on earlier chips?

2) What's with the mention to PPC? Just CPUs that aren't supported any more? And if so, why are they there?

3) What does all that 0x000 stuff refer to?

Basically I'm not sure how to 'read' what you've written — what the relevance of each line is and what to look out for. Sorry again for my ignorance. But I'd rather look stupid now and learn something!

1. Could be.

2. Old code, why they don't even remove it is beyond my understanding

3. AFAIK it's the code for the CPU (family) name.

 

[jdclifford]

in the last few betas I have seen zero difference or anything new or better, what are they actually changing

maybe just some security updates?

 

[keysofanxiety]

1. Could be.

2. Old code, why they don't even remove it is beyond my understanding

3. AFAIK it's the code for the CPU (family) name.

Thanks again JP. I appreciate you taking the time to respond. I'm fascinated about all this stuff.

Just a case of waiting until the refresh! I wonder what we'll see.

 

[cube]

You can't execute programs (besides the programs by Apple) at all or (if a x86 processor is being simulated) just with a significantly high impact on performance.

Of course you would be able to run 3rd party programs compiled for ARM.

 

[mijail]

You could emulate x86 code, but it's so complex that anyone who seriously tried, failed.

Whaaaat? How "failed"? Ever heard of VirtualPC? I used it for years to run Windows98 on a CRT iMac.

In addition x86 is a CISC architecture vs ARM is RISC, (x86 can execute more complex machine instructions and is not limited to one instruction per clock cycle),

I think you have that pretty backwards. CISC is characterized by more complex machine instructions... but "complex" is bad, because that meant that a single instruction traditionally needed multiple cycles; in contrast, one of the advantages of RISC is that they could reach 1 Instruction Per Cycle much more easily. CISC architectures had to fight hard to approach the same 1 IPC.

Anyway, that fight happened 15 years ago. Architectures converged so much that talking about differences is mostly academic now. AMD64 is a RISC with a CISC interface – which is a burden necessary for compatibility.

which would result in x86 code being emulated on ARM to take about 50% hit compared to native execution, which is huge.

Mhm. Is this one of those cases where 95% of people mentioning percentages are making them up in the moment?

 

[cube]

Maybe it's a header definition just appearing in BSD?

 

[justperry]

Thanks again JP. I appreciate you taking the time to respond. I'm fascinated about all this stuff.

Just a case of waiting until the refresh! I wonder what we'll see.

Right now I don't see any proof of an upcoming ARM Mac in this Machine.h file.
I could be wrong though.

----

Still Mountain lion visible in Software Update.

 

[dogslobber]

The ARM stuff is a hoax I'm beginning to wonder. I mean where are the web fingerprints?

Mozilla/5.0 (Macintosh; ARM Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14

 

[Peace]

The ARM stuff is a hoax I'm beginning to wonder. I mean where are the web fingerprints?

Mozilla/5.0 (Macintosh; ARM Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14

I know right ?

Mozilla/5.0 (Macintosh; Intel Mac OS XI 13_0_1) AppleWebKit/1602.2.14 (KHTML, like Gecko) Version/12.1 Safari/1602.2.14

 

[fredr500]

I know when IBM was making the processor for Macs they made more $$ per machine than Apple did. I see the ARM talk as a chance for Apple to quit paying Intel for processors and keep the profit in-house.

 

[xflashx]

Of course you would be able to run 3rd party programs compiled for ARM.

Of course you can run them. The question is... just because Apple changes to ARM, all companies start to re-write their programs so they can run on ARM chips? I believe that it costs a lot of $$$ to do that, even if they re-wrote them I don't think they will outperform the programs written for x86 cpus.
Sometimes I am happy to find programs which are also available on mac (not the popular ones, I mean scientific programs). I believe porting those programs would be too expensive so those companies will drop macOS support from their programs.

In the end you will have a lot of software which have to be emulated, and then there will be a performance hit.
I can't afford that because I need my Mac to be capable of calculating mathematical simulations, a lot of other "pro" users which are using "pro" software will face the same problems.
Besides that, there are people which need their Macs to run windows sometimes, what will they do?
They won't buy Macs anymore but those computers which can run their software properly.

And just because new ARM chips have better geekbench results than x86 processors, x86 processors are way more capable than ARM processors (besides appearing slower in benchmarks).
I don't see any advantages, just disadvantages for their users, us.

 

[cube]

I know right ?

Mozilla/5.0 (Macintosh; Intel Mac OS XI 13_0_1) AppleWebKit/1602.2.14 (KHTML, like Gecko) Version/12.1 Safari/1602.2.14

Mozilla/5.0 (Macintosh; ARM iOS X 13_0_1) AppleWebKit/1602.2.14 (KHTML, like Gecko) Version/12.1 Safari/1602.2.14

 

[arosania]

Cosmetic change:

No more flags in input menu.

 

[a_coorn]

Whaaaat? How "failed"? Ever heard of VirtualPC? I used it for years to run Windows98 on a CRT iMac.



I think you have that pretty backwards. CISC is characterized by more complex machine instructions... but "complex" is bad, because that meant that a single instruction traditionally needed multiple cycles; in contrast, one of the advantages of RISC is that they could reach 1 Instruction Per Cycle much more easily. CISC architectures had to fight hard to approach the same 1 IPC.

Anyway, that fight happened 15 years ago. Architectures converged so much that talking about differences is mostly academic now. AMD64 is a RISC with a CISC interface – which is a burden necessary for compatibility.



Mhm. Is this one of those cases where 95% of people mentioning percentages are making them up in the moment?

It's a popular myth that RISC is better because of 1 instruction per clock, yes, it's cleaner, but Intel has done some amazing optimisations to its CISC architecture, where it almost emulates RISC when there's an advantage but is able to execute complex CISC instructions where needed, whereas in RISC you use simpler instructions to build up more complex ones, resulting in more complex, less efficient compilers and assemblers as well as generally code that is not as well optimised.