Linked by Thom Holwerda on Sat 3rd Feb 2018 14:15 UTC, submitted by Drumhellar
Mac OS X

When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall.

This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.

Thread beginning with comment 653455
To read all comments associated with this story, please click here.
Comment by Kroc
by Kroc on Sat 3rd Feb 2018 14:48 UTC
Kroc
Member since:
2005-11-10

I'm certain this is one step toward moving away from Intel chips. A chip that has no 32-bit hardware at all is going to require a significantly less number of transistors and therefore less heat / more room to do something else. It's also much easier to emulate or transpile the Intel code if you're only dealing with one (much cleaner and newer) arch.

Reply Score: 3

RE: Comment by Kroc
by Kochise on Sat 3rd Feb 2018 14:58 in reply to "Comment by Kroc"
Kochise Member since:
2006-03-03

Well, if you delete 32 bits from 64 bits, you actually get... 32 bits. I bet these legacy 32 bits are the foundation of the current 64 bits architecture. So you better not ditch it out just because to woke up on a left foot.

Btw, if you're really into going to get rid of such "nuisance", you also better get rid of all these useless emulation layers. Out DOSBox, out Mame, out 32 bits Qemu, out old and retro tech. Welcome all new shiny 64 bits God !

Reply Parent Score: 7

RE: Comment by Kroc
by Brendan on Sat 3rd Feb 2018 15:25 in reply to "Comment by Kroc"
Brendan Member since:
2005-11-16

Hi,

I'm certain this is one step toward moving away from Intel chips. A chip that has no 32-bit hardware at all is going to require a significantly less number of transistors and therefore less heat / more room to do something else. It's also much easier to emulate or transpile the Intel code if you're only dealing with one (much cleaner and newer) arch.


For 80x86, the only major difference (for user-space code) between 32-bit machine code and 64-bit machine code is that 64-bit machine code is allowed to have "REX prefixes". In other words, deprecating 32-bit apps wouldn't make any difference for application emulators - they'd still need to emulate all 32-bit instructions to make 64-bit code work (excluding an extremely small number of instructions that were recycled to make room for REX prefixes - mostly one "inc" and "dec" group of opcodes).

The reason Apple is deprecating 32-bit applications is much more likely to be related to the cost of maintaining a compatible kernel API and shared libraries.

- Brendan

Reply Parent Score: 9

RE: Comment by Kroc
by teco.sb on Sat 3rd Feb 2018 15:47 in reply to "Comment by Kroc"
teco.sb Member since:
2014-05-08

As someone who has done both x86 and x86-64 assembly programming, I can tell you that is not the case. Even in long-mode, the AMD64 additions still seems to favor 32-bits operations over 64-bits ones.

Instructions are shorter (a function of x86's variable instruction size) when you work on 32-bit registers and instructions referencing the extended registers (r8-r15) require an extra byte, making them awkward. As an example, in long-mode adding 2 32-bit registers is only a 2-byte instruction, but requires 3-bytes for the same operation on 64-bit registers. That's a 50% increase in code size for something you may or may not need.

I think the problem with supporting 32 and 64-bit applications is in the syscall mechanism. If you take a look at Linux's syscall numbers, you will notice they are completely different for each architectures. This is true for every kernel (as far as I know). So in order for the kernel to be able to run a 32-bit compiled program in a 64-bit kernel, it first needs to identify that the application is going to be making 32-bit syscalls, and then translate those calls to the equivalent 64-bit syscall every time.

I will also add that the syscall convention for x86 and x86-64 are completely different. So it really is a translation for every kernel call.

Reply Parent Score: 12

RE[2]: Comment by Kroc
by bhtooefr on Tue 6th Feb 2018 11:35 in reply to "RE: Comment by Kroc"
bhtooefr Member since:
2009-02-19

Some of this might be about ARM, where ARM has two different ISAs for 32 and 64-bit modes?

Note that the A11's cores don't even have an AArch32 decoder, just AArch64.

Reply Parent Score: 2

RE: Comment by Kroc
by galvanash on Sat 3rd Feb 2018 21:15 in reply to "Comment by Kroc"
galvanash Member since:
2006-01-25

A chip that has no 32-bit hardware at all is going to require a significantly less number of transistors and therefore less heat / more room to do something else.


It can simplify some things from the perspective of the programming model, and this may allow some small but advantageous hardware changes. However, as a piratical matter, most architectures that support mixed 32-bit/64-bit ISAs do so by simply using the 64-bit hardware - there is no "32-bit hardware"...

In other words there is no significant hardware cost to to supporting 32-bit code using 64-bit hardware and whatnot - you just ignore half the contents of the registers. The only cost real cost comes in decode and some bookkeeping, but generally that cost is mostly significant.

Reply Parent Score: 4

RE: Comment by Kroc
by Poseidon on Sun 4th Feb 2018 09:04 in reply to "Comment by Kroc"
Poseidon Member since:
2009-10-31

Not at all. This will make it easier for apple to maintain software and have it be even better and faster.

In a computer science point of view strictly, this allows the default precision be higher for mathematics and numbers, a very integral part. Handling more numbers at once without having to process more code or loops is great for energy efficiency and code efficiency, and this is the same for all 64 bit CPUs using 64 bit instructions instead of 32 bit instructions.

Now that being said, switching from intel to arm is mostly just a compiler optimization task, and iOS and macOS are not that different on the entire base system, which means that it's already technically been done a while back.

All in all, switching ot another architecture is just a matter of them optimizing their compilers.


The move to 64 bit is welcome and I love that it's finally happening, as any developer will tell you. You can just worry about supporting the newest technologies and languages which are optimized for 64 bits, the same with the IDEs, without having to do alternative code segments for 32 bit sections.

I apologize for the long rant, but the myth of "Oh they're switching now because of X!" has to stop at some point.

Reply Parent Score: 0

user78 Member since:
2011-07-06

HAS NO HARDWARE LIMITATION FROM THEIR 64BIT VERSION IS BASED ON IA64 AND EM64T, SO GET YOUR FACTS RIGHT TROLL...AND PEOPLE THUMB YOU..HOW A SHAMED YOU DON'T REASEARCH FIRST BEFORE DECIDING WHEN HE IS WRONG

AND PROVED MY POINT I AM RUNNING PURE 64BIT OS ON APPLE LATELY ON MY OLD I7 INTEL CPU...IT SHOWS 64BIT HARDWARE SUPPORT IA64 AND EM64...NO AMD64 FOR SURE..APPLE DON'T SUPPORT AMD64 CODE..OR ELSE LET HACKINTOSH TRY TO EMULATE IA64 OR EM64 ON THE KERNEL

SO ITS ONE STEP TOWARD DITCHING ROOT AND 32BIT ACCESS FROM AMD HACKINTOSH USERS..ITS ILLEGAL FOR AMD USERS

Edited 2018-02-06 17:11 UTC

Reply Parent Score: 0