ARM64 Vs ARM32 -- What's Different For Linux Programmers? (edn.com)

New submitter DebugN writes: When ARM introduced 64-bit support to its architecture, it aimed for Linux application compatibility with prior 32-bit software on its architecture. But for Linux programmers, there remain some significant differences that can affect code behavior. If you are a Linux programmer working with — or will soon be working with — 64-bit, you might want to know what those differences are, and this useful EDN article says it all.

Comments

Re:ARM32? ARM64?

[Anonymous Coward]

Vegeta, what does the scouter stay about his ARM level?

I'm not a programmer...

[Anonymous Coward]

But if the answer isn't "32bit exactly", i will be really confused...

Re:I'm not a programmer...

[OrangeTide]

The instruction set for ARM64 is a bit more like MIPS than ARM. I don't think it would matter to an end user, but this new 64-bit mode has made for a lot of extra work for compiler developers as many of the optimizations developed over the years are no longer effective for 64-bit code. And the bits of operating system and library code that was written for 32-bit or Thumb has to be rewritten as if ARM64 was a totally alien architecture.

It came as a big surprise really, because years ago when ARM Thumb was added as an extension it was somewhat compatible with the old instruction set, at least in the assembler syntax. That made it relatively easy to port between the two modes. Thumb mode instructions that are half as big, but still operate on 32-bit values, but those instructions are more limited in terms of what they can do and what arguments they will accept. On the Game Boy Advance, the thumb operations could run twice as fast as the non-thumb operations because the 16-bit bus for cartridges was relatively slow compared to the CPU performance.

ps - I prefer to call it aarch64 or ARMv8.

Re:I'm not a programmer...

[TheRaven64]

The instruction set for ARM64 is a bit more like MIPS than ARM

That's not really true. MIPS has no condition codes, has branch delay slots, has no PC-relative addressing and no complex addressing modes. About the only thing where AArch64 is more like MIPS than AArch32 is in having a non-architectural PC, which is a decision made by most modern architectures as making the PC a possible destination register complicates a lot of things microarchitecturally. A few similarities between AArch32 and AArch64 that are not shared with MIPS:

• They both have a set of condition codes.
• They both have conditional moves that operate on the condition codes (though AArch32 also has a lot of other predicated instructions).
• They both have complex addressing modes.
• They both have the same SIMD extensions.
• They can both load and store more than one integer register at once (AArch32 has load/store multiple, which are horrible to implement in a complex pipeline, AArch64 has load/store pair).

I don't think it would matter to an end user, but this new 64-bit mode has made for a lot of extra work for compiler developers as many of the optimizations developed over the years are no longer effective for 64-bit code

Speaking as a compiler writer... no. About the only AArch32-specific optimisations relate to if-conversion (which you can still do with a conditional move, unless they would require a predicated load / store) and prolog / epilog compression (which now you do with load/store pair instead of load/store multiple).

I prefer to call it aarch64 or ARMv8

AArch64 an ARMv8 are not interchangeable. ARMv8.1 is also AArch64, though includes a few nice additions, such as atomic read-modify-write instructions.

Re:I'm not a programmer...

[dotancohen]

The instruction set for ARM64 is a bit more like MIPS than ARM

That's not really true. MIPS has no condition codes, has branch delay slots, has no PC-relative addressing and no complex addressing modes.

I think that OrangeTide meant that the experience of porting to ARM64 is like the experience of porting to MIPS. He mentions specifically that there are major code changes (i.e. in optimizations) that need to be done which weren't necessary when porting to i.e. Thumb. Those code changes make the port experience similar to porting to another architecture altogether, i.e. MIPS.

Re:I'm not a programmer...

[OrangeTide]

Right. A lot of the conditional instructions have been dropped. And a lot of the semantics of existing instructions have changed. It is true that operations still modify status flags to handle conditions, versus MIPS which has branches that perform the comparisons themselves. Obviously the new architecture is not like MIPS, SPARC or POWER, but I'd argue it's not much like ARM either. Aarch r31 is a bit like MIPS r0 though, in that it is a zero value if you read it (rsp). Although it's a bit overloaded on ARM and it is a real register that can be saved and restored, while on MIPS it's always zero.

Re:ARM32? ARM64?

[Anonymous Coward]

I'm wrestling with how to answer all these ARM questions.

tl;dr;

[viperidaenz]

It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel", implying ARM 32bit CPU's don't run on the latest kernels. But they do.

Re:tl;dr;

[Guy Harris]

It's mostly nothing to do with ARM and much to do with "Moving to a later Linux kernel",

You're thinking of the third item in their list.

The first item in their list does have to do with ARM; its register set is different, and OS APIs for debugging have platform dependencies - in particular, the Linux kernel handled A64 differently from A32 - and those particular developers happen to be using ptrace() and had to handle A64 differently.

The second item in their list has to do with the C library doing more atomic load/store operations on A64 for some reason; they speculate that it's "to better support multiprocessor systems."

The problem here is that the article had a misleading title; it was "ARM64 vs ARM32 -- What's different for Linux programmers" when it should have been "ARM64 vs ARM32 -- What's different for people working at a company whose core technology is a record and replay engine, which works by recording all non-deterministic input to a program and uses just-in-time compilation (JIT) to keep track of the program state". What Undo Software are doing is rather specialized and system-softwareish, and they run into issues that wouldn't affect the majority of programmers; those are the issues they're talking about.

Re:tl;dr;

[bluefoxlucid]

I'm starting to wonder what really makes an architecture 32- or 64-bit. So far as I can tell, it's just the pointer size. 32-bit architectures can have 64-bit word sizes (double-word); the processor can internally carry 256-bit cache lines and have enormous data buses and still be an 8-bit 6502.

Seriously, you could make that: a 6502 with pin-outs for 256-bit data buses, but 8-bit addressing. Prefetches 32 words at once through one cycle into CPU cache. It would be nonsense. The Athlon 64 architecture used to internally predict register usage and break the 64-bit GPRs into 32-bit GPRs, and add those plus the remaining GPRs to a set of internal 32-bit registers, which it used to preload registers: when you wanted to load an address into a register, it would have predicted this action and already cached it in an internal register; if you wanted to add a memory location to a register, branch prediction would have that location in an internal register, and do an add of one register to another. It used its 64-bit data bus to prefetch two words at a time: rather than prefetching the next 8 words by 8 memory bus accesses, it would prefetch 8 words in 4 memory bus addresses--doubling memory access speed compared to a 32-bit architecture with the same FSB clock.

The key point of a 64-bit architecture is now the ability to address 64-bit memory locations. You can mess with 32-bit architecture to use 64-bit or 128-bit operations internally where appropriate--double words and other large data objects.

Re:tl;dr;

[AReilly]

Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.

Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.

Re:tl;dr;

[mikael]

With 8-bit and 16-bit systems, this was the width of the data bus, while memory was mostly limited to 64Kbytes, but there were all sorts of funky paging that could swap in and out 16K blocks. With 32-bit and 64-bit systems, it's the theoretical maximum amount of uniquely addressable memory; 32-bit = 4 Gbytes, 64-bit = 1 Exabyte of storage. But CPU performance is being improved by using 128-bit and 256-bit wide data bus architectures to support SIMD instruction sets like AVX and 3Dnow!

Re:tl;dr;

[Bert64]

Ofcourse the other architecture in the embedded space is MIPS, and MIPS64 support has been around for a long long time... The move to 64bit was a perfect opportunity for MIPS to expand their market share as MIPS64 was tried and tested while ARM64 was completely new.

Re:tl;dr;

[iggymanz]

Now that was funny, first sentence making some kind of absolute statement about people's understanding, but then you hedge in later sentences with "usually" and then "probably".

the i860 was marketed by intel as a 64 bit processor because of the 64 bit graphics registers, but it had 32 of the 32 bit general purpose registers and 32 bit bus.

Re:tl;dr;

[viperidaenz]

There are many instructions in x86 that operate on values larger than 32 bits.
MMX comes with 8 64bit registers
The movq instruction can move a 64bit value between memory and the MM registers.

Re:tl;dr;

[Anonymous Coward]

Will people *please* stop saying that hardware "runs on" software: it's the other way round!

(If you want to say that a piece of hardware "runs" some software, that's perfectly acceptable -- but not "runs on".)

Re:tl;dr;

[viperidaenz]

Unless your 32bit CPU supports PAE, then it can address 36 bits of memory.

Re:tl;dr;

[phantomfive]

Seriously, you could make that: a 6502 with pin-outs for 256-bit data buses, but 8-bit addressing

I'm not seeing what you're saying here. How would you be able to address that memory from within the 6502 instruction set, with 8-bit addressing?

Re:tl;dr;

[enriquevagu]

Of course the title is misleading! For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries (for example, synchronization). Still, the document makes interesting points, such as different behaviour of the compiler (which apparently removes locks in ARM32 but not in ARM64) which could impact performance, especially for highly concurrent applications.

Re:tl;dr;

[Anonymous Coward]

How would you classify a CPU like the Z80?
It has an 8-bit databus and 8/16-bit registers but internally it is performing all instructions through a 4-bit ALU.
That why even a register-register addition takes 4 cycles, not counting the memory refresh.

It can do 16-bit additions (or left-shift if you so wish) with a single instruction, but I sure wouldn't call it a 16-bit CPU.

Re:tl;dr;

[Guy Harris]

Of course the title is misleading! For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries (for example, synchronization).

Unless you're one of the user-space programmers writing the compiler or the system libraries. :-)

The programmers at Undo are programmers like that, not typical user-space programmers writing code for which the ISA doesn't matter.

(And a fair bit of kernel programming is done with the ISA hidden by the compiler and lower-level kernel code, for that matter.)

Re:tl;dr;

[TheRaven64]

For a user-space programmer, the ISA is completely hidden by the compiler and the system libraries

There are a few places where it might matter. For example, AArch64 can do atomic operations on pairs of pointers. This is particularly important for some of the RCU code in the Linux kernel, but will be similarly important for some userspace atomic operations. If you're writing a userspace threading library (fairly niche) then the different structure of ucontext_t will be important. It can also be important if you're looking at the ucontext_t that's delivered as an argument to signal handlers (though most signal handling code doesn't do anything with it).

The barrier elision work is based on something that one of my students did. It hasn't yet been applied to AArch64 because the memory model is slightly different and they're working with some of my colleagues on a formal proof that the transforms would be valid, but it will appear there at some point. One of the slightly tricky things with ARMv8.1 is that atomic read-modify-write instructions are sometimes slower than the equivalent load-exclusive, modify, store-exclusive loop, depending on the microarchitecture.

Re:tl;dr;

[TheRaven64]

It's only easy on most modern ISAs because they have unified integer and address registers. Usually we use the size of an address register and implicitly assume that it's the same as the size of an integer register. This gets a bit confusing in some cases: I played with a highly specialised DSP a few years ago that had 64-bit integer registers but only 256-bit address registers (it was intended for a streaming computation that had very few temporary values, though the addresses were all to 64-bit words [it only had 64-bit load and store instructions], so it could address 2KB of SRAM). Was that an 8-bit processor? Generally, for this kind of thing, the designation just doesn't make sense and it's whatever the marketing folks decide (the same ones who decided that the Pentium was a 64-bit processor because it had 64-bit integer operations).

Re:tl;dr;

[TheRaven64]

It would have been, except for one problem: The owners of MIPS (Imagination Technologies) did not own any MIPS64 IP cores. They only had 32-bit cores available to license. All of the 64-bit cores were either developed by third parties, or retained by third parties during the many sales of the MIPS IP. Oh, and they decided to go batshit insane and make a modern ISA with MIPSr6 that reuses opcodes that were defined in MIPS III to MIPSr5 with incompatible definitions (e.g. replacing the branch-likely instructions, which have a delay slot that's only reached if the branch is taken, with compact branches that don't have a delay slot) and claiming that you can do binary translation to work around the differences (but not providing a reference implementation of the binary translation).

Re:tl;dr;

[bluefoxlucid]

You'd say, "Get the memory at 0x0c00".

It would load the memory at 0x0c00-0x0c0F into CPU cache, and copy the 0x0c00 address into a register. If you then tried to add 0x0c0A to that register, it would read it from cache.

Re:tl;dr;

[phantomfive]

Oh, so still more than 64k wouldn't be accessible to the programmer

Re:tl;dr;

[bluefoxlucid]

Right, just the internal architecture of an 8-bit processor is for some reason now 64-bit.

Re:tl;dr;

[phantomfive]

Oh. I guess I think of "32" or "16" bit in terms of the ISA, not so much the other stuff.

Re:tl;dr;

[bluefoxlucid]

Which also doesn't make much sense, since there's not much advantage and a lot of disadvantage to 64-bit ISA. The x86-64 ISA adds extra registers and other instructions which would be useful to 16-bit processors, but it also makes word-sized values 64-bits wide by default.

Re:tl;dr;

[phantomfive]

Which also doesn't make much sense, since there's not much advantage and a lot of disadvantage to 64-bit ISA.

The primary advantage for consumer devices is that you can access more RAM.

The x86-64 ISA adds extra registers and other instructions which would be useful to 16-bit processors

That's true, they should have been added years ago.

but it also makes word-sized values 64-bits wide by default.

Kind of......for a lot of instructions, the default is actually 16 bits. For a mov command, the default is to move 64bits, but you can also specify 8/16/32 bits. I'm not sure it matters too much practically what the 'default' is, though.

The x86-64 is indeed a hybrid monstrosity, whose only redeeming feature is backwards compatibility.

That's easy

[pushing-robot]

One has a lot more arms.

Re:That's easy

[dotancohen]

One has a lot more arms.

Are you suggesting that an arms race is imminent?

So in summary

[NaCh0]

There are no changes for programmers in general. Only the compiler writers need to care. (as usually happens with new cpu architectures)

Re:So in summary

[Tablizer]

Can we have that in writing, please?

Re:So in summary

[Tablizer]

worse, Perl

C Programmers on Linux, not "Linux Programmers"

[Anonymous Coward]

This will have absolutely no effect to the majority of programmers that use a higher level language such as Java or Objective-C.

As the article shows examples, only Assembly and C have changes from the 32 bit version, which are to be expected. Not a big surprise for anyone. I am sure my Python code will run the same as it did on ARM32.

Re:C Programmers on Linux, not "Linux Programmers"

[Anonymous Coward]

I am sure my Python code will run the same as it did on ARM32.

Unless the guys who write CPython get tripped by these differences

Re:C Programmers on Linux, not "Linux Programmers"

[Lisias]

Guys that assume sizeof(int) as 32 bits, instead of using "sizeof(int)" explicitly will have a bad time.

And believe me, they're at loose even nowadays.

Re:C Programmers on Linux, not "Linux Programmers"

[fnj]

This will have absolutely no effect to the majority of programmers that use a higher level language such as Java or Objective-C ... only Assembly and C have changes from the 32 bit version

OMG, what drivel. Objective C is a superset of C, and as such shares all of C's characteristics.

Re:C Programmers on Linux, not "Linux Programmers"

[interval1066]

Its so easy to get the bit width of an int on any hardware it makes me cringe when embedded programmers don't do it.

Re:C Programmers on Linux, not "Linux Programmers"

[0123456]

Didn't Microsoft go full retard and make 'long' a 32-bit type on 64-bit Windows?

Re:C Programmers on Linux, not "Linux Programmers"

[Anonymous Coward]

That should be (sizeof (int) * CHAR_BIT). POSIX requires CHAR_BIT to be 8, so you can reasonably choose to also make that assumption on Unix-ish systems. But on some architectures CHAR_BIT can be 16 or greater, e.g. on a DSP which only has floating point arithmetic. It could emulate 8-bit chars, but it'd be quite slow.

Portable C programming is actually quite easy, but you just have to stay mindful. It helps if you stick to unsigned arithmetic when practical, which is usually the case because unsigned is the natural type for most things you do in a program. Pro tip: Ignore the advice of those who advocates using signed types.

One benefit of being a C pedant (or aspiring to be one) is that you tend to avoid common mistakes. If you're constantly on the look-out for misuses of char and other typing issues, then spotting bad pointer handling and other stuff becomes second nature, as the former requires more experience. And you naturally avoid type punning, casting, and abusive use of types in general.

Also, you come to realize that fixed-width types like uint32_t aren't as useful as most people think. People use them as a crutch so they don't have to think about their code as much. What you really care about are the limits of the data types. When you have to stop and, for at least a second, pay attention to these things, you'll find that the quality of your code increases and your bug count decreases. And where you do make assumptions, you learn to add the constraints to the code, e.g. by using static_assert.

People wonder why the C committee doesn't narrow the number of choices compilers can make. It's regularly brought up at the committees. One of the counter arguments is IEEE floating point. On the one hand, it's made it easier to write portable floating point code. OTOH, it's made it _impossible_ to utilize novel and more high-performance floating point representations, e.g. unum floating point, which ultimately could make code faster and less buggy.

Another example: Eventually systems might want to make use of tagged pointers for security. This will break much non-standard C code that improperly casts function pointers.

These things matter, for many non-obvious reasons.

Re:C Programmers on Linux, not "Linux Programmers"

[ctrl-alt-canc]

I am a FORTRAN programmer on Linux, you insensitive clod!

Re:C Programmers on Linux, not "Linux Programmers"

[Antique Geekmeister]

> Wow! Really sorry to say that sizeof(int) is 32 bits even on a 64-bit architecture.

Really, it's not. "int" varies depending on compiler and architecture. See below from www.unix.org.

                http://www.unix.org/whitepaper...

It's precisely your kind of assumption from limited experience that breaks cross-compilation and multi-platform work.

Re:C Programmers on Linux, not "Linux Programmers"

[TheRaven64]

They did break a lot of code, because a lot of code assumes that you can use long instead of intptr_t and store a pointer in a long then recover it later. The things that didn't break were doing really stupid things like putting long (instead of int32_t) in packed structs representing on-disk file headers (and Microsoft was responsible for shipping quite a few of those headers).

Re:C Programmers on Linux, not "Linux Programmers"

[Dog-Cow]

You do know that MS Windows has existed longer than the int32_t typedef, right?

Re:C Programmers on Linux, not "Linux Programmers"

[TheRaven64]

Yes and no. Yes, longer than the C99 standard int32_t typedef. No, not longer than the MS-specific int32 typedef, which was around at least in Windows 3.0 and inherited from Microsoft's DOS C toolchain.

Re:C Programmers on Linux, not "Linux Programmers"

[Lisias]

Wow! Really sorry to say that sizeof(int) is 32 bits even on a 64-bit architecture.

Q.,E.D. :-)

The size of the int is a compiler decision, not architectural one. On my old 8 bits time, the sizeof(int) was 16 bits.

Does ARM64 matter?

[Anonymous Coward]

ARM64 has been coming for so long one wonders if it really matters anymore.

Yes, it has reached cell phones and tablets - but nobody is running anything but iOS or Android on those.

ARM64 was supposed to bring us standard motherboards with a standard, documented boot system so that Linux could treat ARM64 just like AMD64 for booting purposes - one standard bootloader instead of custom stuff for every board that quickly becomes a support nightmare.

Yet years after announcing, just like Power8's move to the masses and other grand announcements in computing's history, it is still vapourware. And in the meantime Intel is making significant progress with trimming power consumption that the ARM64 market outside of iDevices may have vapourized.

Re:Does ARM64 matter?

[timmyf2371]

The market for mobile devices which might run ARM is far bigger than the market for laptops and desktops.

Re:Does ARM64 matter?

[Tablizer]

Perhaps, but also less profitable.

Re:Does ARM64 matter?

[angel'o'sphere]

Every modern car with lane detection, pedestrian detection, sign detection, break assistance, collision detection (and in ten ears that will be "state of the art" and become mandatory for every car by law, just like ABS and ESB(? ESS?) became a year ago) has a dozen of ARMs and a few DSPs.
So yes: the simple idea of that Lady in the late 1980s is now the most sold high level processor on the planet.
Nevertheless there are still odd 8 bit and 16 bit processors sold as well. After all if you save 1$ in a device and ship 500 millions of them, you save 500 million dollars.

Re:Does ARM64 matter?

[TheRaven64]

We have a few ARMv8 boxes. One from AMD has a fairly standard layout motherboard and will fit in most PC cases. One from Cavium is in a standard rack-mount case (and, with two sockets and 48 cores per socket, is serving as a very useful test bed for lock contention in a variety of parts of the kernel).

This one goes to 64

[Anonymous Coward]

It's not 32. You see, most blokes, you know, will be playing at 32. You're on 32 here, all the way up, all the way up, all the way up, you're on 32 on your arm. Where can you go from there? Where?

- Nigel Tufnel

Details

[Galaga88]

You see, when you have ARM32 vs ARM64 you have to remember that 64 is at least twice as much as 32. So you're going to need to use larger instructions in your program or you're going to have a lot of empty space. Because your functions can go twice as far, you're going to need more data highways to get there without all the congestion. It's like moving from a crowded boulevard to an expressway.

When it comes to mobile apps, which is where you're going to be programming the ARM, these wider highways occupy valuable space on your mobile board, but it's worth it to reduce congestion by at least a half. Also, because you have larger bits, you can get more numbers in your apps without having to stress the fixed point unit. This means fonts take up less space and as such you can use more serifed typefaces.

This answer brought to you by That Guy Who Clearly Bullshitted Through His Interview and Got Promoted To Manager Last Week.

Re:Details

[TheRaven64]

You see, when you have ARM32 vs ARM64 you have to remember that 64 is at least twice as much as 32. So you're going to need to use larger instructions in your program

You're joking, but that's actually true. Most AArch32 code these days uses Thumb-2, where most common instructions are 16 bits, a few are 32 bits. There's no Thumb-3 (yet) for AArch64, so all instructions are 32 bits. There almost certainly will be Thumb-3 at some point, though it is likely to be a little while coming and involve profiling a lot of code to determine what the most common instructions are (and there's no point in doing that until the compiler back ends have stabilised a bit).

Re:Trump vs Clinton -- Whats different for voters

[bbruun]

Danm you got some issues. You do know that its been 70 years since all of what You are descrbing happend (besides UKIP) ?

lisaparratt is right on and your comment shows so.

I live in Denmark, you know, among one of the first democratic countries in the world (besides the original democracy Greece), and our feet crumble when we see and hear the US talk about human rights, equal rights, and your so called democracy (which is a republic which is not a democracy which many people in and form the US claims).

Socialism the way you talk about it and in general how the US portrais it is so far off that it makes Europeans laugh over the ignorance. Socialism is anything but the facist, stalinistic or nazi regimes you mentione. They are all dictatorships, arisen from failed attempts to implement different types of governments.
One of the best ways to view the success of a country, a regime, is to look at how many of the population is insjail/prison. The US has over 7 million people in jail (that is 716 per 100000 capita).Denmark has 61 per 100000 aka 8% of what the US has.

Socialism, in a capitalistic country like Denmark, is more like the US than you think yet we don't let our people starve in poverty because the rich needs more money. We do take care of each other instead of thinking egoistically about "what can I get" instead of "what do I need" and then make sure to give so everyone has "what I need" which includes free child care, education, healtcare and pension for the elder and care for them as well. All free for the individual. All of this costs hence the tax system which is between 40-60% of your income (depending on your income level) and 25% sales tax etc. like any other country.
It works, it works al ot better than the US system which has for the past few decades just been on a downhill slope dragging the rest of the world into an abyss due to "problems at home" that apparently is "someone elses fault".

So thank you for your 70 year old words of wisdom, which are in some serious need of some updates.

Re:Trump vs Clinton -- Whats different for voters

[silas_moeckel]

It looks about that way from here in the states as well.

Re:Trump vs Clinton -- Whats different for voters

[The Wild Norseman]

Hang on, I think I'm getting it. Usually people use car analogies on /. but you're talking about the US and Denmark, right? So in this case, Denmark is 64-bit and the US is only 32-bit? Or are you talking about ARMs as in "the right to keep and bear ARM [chips]"?

Re: ARM32? ARM64?

[LoRdTAW]

[goku@dragonball]$ scouter -h
It's over
Segmentation fault
[goku@dragonball]$

Re:2+ years late

[unixisc]

iOS only has to bother about Apple's A series of processors, and not the myriad variety of ARM CPUs from different vendors, such as Qualcomm, Freescale, TI, et al Not the same challenges

Re:ARM32? ARM64?

[davester666]

You can buy a MS Surface really cheap if you are interested in that.

Re:Bring on the ARM desktops already

[MerlynEmrys67]

You haven't played with any of the arm tablets running android?

Been around for a couple years now

Re:Trump vs Clinton -- Whats different for voters

[TheRaven64]

If you're going to define socialism by the fact that the NAZIs and the USSR had socialist in their name, then you also need to define democratic based on the Democratic Republic of Congo. Or you can try using the definitions that you'll find in a politics textbook and then people might be able to have a sensible conversation with you.

Re:Trump vs Clinton -- Whats different for voters

[Hognoxious]

what's hilarious are the whacked out ideas europeans have of socialism.

We're perfectly aware what it means. People on your side of the pond use it to mean anything you don't like. If I was you, right now I'd be cursing Craig Joubert, the neighbour's dog and the weather for being socialists.

'nazi' literally means national socialist.

Greenland literally means "A country that is green". Doesn't alter the fact that it's predominantly white.

There is a connection, anybody know what it is?

Then there's the insane social and economic policies of places like sweden, where man-hating feminists rule the roost, and citizens pay 75% of every kronor back to the state (50% income + 25% vat).

You can't just add percentages like that. Protip: when dealing with percentages, consider what they're percentages of.

Re:2+ years late

[unixisc]

Thanks, but doesn't quite change what I implied. Be it the instruction set or the peripheral set, iPhones, iPads and iPods use the same CPU from Apple's former Palo Alto Semi division. And likely the same peripheral interfaces. Going into different SPI/I2C/USB mode settings ain't trivial, and involves repeated low level programming. Whereas if it's done once on Apple's platforms, it can be reused, since Apple ain't gonna change those things in its processors to the point that it cripples the effort required in coming out w/ successors. Which is why Apple probably doesn't need to worry about any Hardware Abstraction Layers

With Android, every platform needs to be separately tested since it's used on tablets/phones made by every CPU - Qualcomm, Freescale, et al. Multiply that by every Android version that's out, and you have major work required from just about every Android related project. Unless - as is the case - the projects just focus on Samsungs and leave the rest to the different vendors/carriers. And then you get the issue of products that don't work on particular tablets or phones, and not merely due to different memory configurations

Undo Software now supports 64-bit ARM

[DebugN]

For those of you who are interested, Undo Software [http://undo-software.com] now supports 64-bit ARM. The press release says that it is particularly useful for developers porting code to new architectures http://undo-software.com/press...