Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

Creatives who want hardware optimized Adobe apps to continue to be fast will care. I wouldn't count on emulation of vectorized code to work all that well.

View on HN

Yep, I think people tend to gloss over how smooth these transitions really were. From a creative professional perspective, they were huge short-term PITA until Adobe etc had everything ported over. Also Excel lost VBA support for several years.

I remember everything audio was a mess although I'd imagine a lot of it had to do with smaller developers lacking resources to port existing software.

Losing VBA support stinks, but do any professional Excel users even consider Office for Mac?

At least for me "professional Excel users" sent out stuff that I could not open, and that is not good for the for the platform.

"Spreadsheet macros" were like hot personal computing shit in 1983. Really not good if you cannot create them in 2008. , (Few complaints about the current Mac MS Office, FWIW) I'm just saying that breaking old stuff often takes year to fix.

No, I get it. I just think that, in general, people who spend a big chunk of most of their work days using Excel kind of consider anything other than Windows MS Office Excel a non-starter.

Adobe's transition was somewhat rough because they took the Carbon route, and then had to do it again to switch over to Cocoa. I expect that now that all their apps are built on Cocoa, the transition will be relatively breezy.

emulating x86 on ARM with any kind of real preformanceis additionally tricky because the x86 archetechure has very strong memory gaurentees (dosent matter if memory is aligned, dosent matter when in the instruction pipeline you access it, etc) that ARM isnt even close to matching.

Emulating that requires a massive performance hit, because you essentially have to check every single memory access to make sure its not doing something invalid on ARM.

…or you design your own ARM CPU that handles unaligned memory accesses fine, and run your emulator on that hardware.

AFAIK the ARM license doesn't allow to invent arbitrary extensions to the ISA. So this might not be allowed.

Apple has an architectural license. I would expect that allows them to add instructions (assuming modern ARM still has the concept of instruction set extensions)

Google didn’t answer that for me, but I found out that there now is a ”cp15 sctlr[1] (alignment bit)”. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... says this about it:

”3.5.1. Alignment faults

If alignment fault checking is enabled (the A bit in CP15 c1 is set), the MMU generates an alignment fault on any data word access if the address is not word-aligned, or on any halfword access if the address is not halfword-aligned, irrespective of whether the MMU is enabled or not. An alignment fault is not generated on any instruction fetch or any byte access.”

From what I've heard, x86 to PPC or ARM emulators are doing dynamic recompiling and instrumentation. It catches the illegal memory accesses and rebuilds the code responsible to add paths with slower code with alignment compensation.

A lot of x86 code is aligned for speed already so it's a pretty safe bet to assume alignment and fix it up if wrong.

Reply on news.ycombinator.com