PINE A64 is the world's first 64-bit expandable Quad Core 1.2Ghz supercomputer, tablet, media center, and more... starting at just $15.

https://www.kickstarter.com/projects/pi ... nav_search

This project is already funded and has 44 days to go...

The PineA64 Is A $15 High-Performance Raspberry Pi Alternative

http://www.dbtechno.com/science/2015/12 ... r-just-15/

Since posting this, I found a good comparison (writeup) on Tom's Hardware between the Pine computer which is a new computer on Kickstarter and the Raspberry Pi:

The 64-Bit Issue

As the Raspberry Pi was designed primarily as an educational device for students to learn computer programming, it stands to lose the most in this market. This is because the mobile market is transitioning to 64-bit hardware and software, and 64-bit programming for Android- and ARM-based devices should grow considerably over the next few years. All current Raspberry Pi devices feature 32-bit support and lack the ability to process 64-bit software, preventing students from developing these types of programs.

http://www.tomshardware.com/news/pine-a ... 30724.html

I'm scratching my head about why it would matter to have a 64-bit CPU in a small board like this. I use a 64-bit desktop computer, but that is because I process huge datasets (tens of gigabytes). As long as you don't need more than 4GB virtual address space or addressing more than 3 or 4 GB of physical RAM in an efficient way (Linux can handle more than that on 32-bit systems via an additional level of indirection - not needed with 64-bit) then there's nothing to gain with a 64-bit CPU. Well, there's 64-bit arithmetic, but that doesn't need 64-bit processing, if it's done the way MIPS does it in their n32 executable model - 32-bit addressing, but access to 64-bit registers for those int64_t additions and subtractions.

With the 512MB or 1GB RAM on these Pine modules what you really gain with 64-bit processing is much larger executables, as every pointer (address) now takes 64 bits..

Edit: I should add that I think it's a nice board, and I will consider it as soon as it's out of the kickstarter phase. But I have problems seeing the point of the must-move-to-64-bit trend described in the referenced links. As I said, it just makes for a larger executable.

I think it's because it doesn't really matter very much, so why not go with 64 bits ? In a few years time that 1GB ram likely will turn into 4GB or more breaking the 32 bit barrier. And they don't want the architecture to be outdated soon. 64 bit architectures are likely to become more common just because transistor and power budgets can support them. In some ways it's easier to work with 64 bits. 64 bit floats have much better precision than 32 bit float numbers and are probably better used for pocket finances. I think at some point people may even go to 128 bits to get quad precision arithmetic. Making the architecture as wide as the widest data element commonly processed is a simple solution. One could in theory use an eight bit machine with bank switching to get at gigabytes of memory, but why bother ?

That Pine module for sure is a looker.

Well, it does matter in that exact case where the board doesn't have that much memory: The executables get larger, and the cache becomes less efficient because every address takes more space (this is an issue also if there's enough RAM to make use of 64-bit addressing).
It's enough of an issue that the most popular executable format on SGI was n32, not n64 (edit: nor o32 - "old" 32). Well, as I mentioned before - that n32 format does give you the best of both worlds: 32-bit addressing, more efficient cache (very important), but access to 64-bit registers for integer arithmetics. I wish there were an ARM architecture that could do that. (Maybe there is - there are so many and I don't have the full overview. But I'm not aware of one.)

And floating point - floating point registers have been handled separately for a long time on common processors, Intel ia32 has had 64- and 80-bit precision long before ia64 and amd64 (aka x86-64) were invented, and the 32-bit Raspberry Pi2 (ARM Cortex A7) has that as well - with its Neon FP unit: 32 64-bit registers, which can be used as 16 128-bit combined registers. Quad precision has been used for ints and floats since the (32-bit) VAX . (I have used VAX, but after a little checking it turns out that the IBM System/370 had 128-bit hardware floating point before that, and some other systems of the era had 128-bit ALUs).
The Cortex A7 has another, non-vector FP unit which also does 64-bit floating point in hardware. Actually the Cortex A53 in the Pine has the same Neon and FP units as the A7..

Yes, as soon as you want to address a ton of memory (virtual or physical) you need 64-bit. But at that point you're unlikely to do your development in assembly.. so it doesn't really matter. As far as I understand, that Pine board cannot be upgraded to hold, say, 16GB of RAM. It can hold 2GB though (previously 1GB), they just updated that kickstarter page with some more info (unfortunately the second link in the OP went dead btw). So if you really need a 64-bit processor, e.g. if you do the kind of processing I do on my desktop, then you can't use that Pine board. You'll have to buy a new board anyway. And at that point it doesn't really matter if the architecture is otherwise exactly the same - because you'll be programming in a high level language on a board with an operating system. I can move transparently between a 32-bit *nix computer and a 64-bit computer with my applications, it's just that the former can only process small datasets. The code I write is exactly the same. It even builds for and runs on a Nokia N900 phone, a different architecture (Cortex A8). Not enough RAM to be useful though.

So, with the Pine, what you get compared to a Raspberry Pi2 is, roughly:

• + Slightly cheaper
• + 64-bit hardware integer arithmetic
• - Larger executables
• - Less efficient L1 cache
• + The Cortex A53 is generally faster than the Cortex A7, and is a bit more power
  efficient

So it's not unlikely that due to the A53 being a newer processor than the A7, the L1 cache may be just that bit faster to compensate for the lower efficiency of 64-bit programs. But I couldn't find any numbers of that.

I fully support that ARM goes 64-bit, but that is in order to compete on the server- and desktop side.. for small memory-limited boards like this it's more of a nuisance and it doesn't in my opinion make any difference for what the user wants to do in the future, with a newer, larger board.

The Pine is a nice board. But to justify it being 64-bit, which, as far as I'm concerned, is a *limitation* for that board, if it had been designed to easily accomodate 16GB or 96GB of DRAM, and if the A53 has a cache system designed to handle that (which I'm not certain about), then yes it would be just the expandable board they claim it to be. As it is, I don't really see it as more expandable than the competitors, and I definitely don't see that their claim of it being a supercomputer can hold up.. that word should be reserved for whatever is the current architecture for weather forecast modelling and the like. My phone is faster than the Cray-1, but it doesn't make my phone a supercomputer even though the Cray-1 was one..

(But yes, if I could put *at least* 16GB on that board, I would buy it as quickly as I could. Because then I could fully replace the computer I lug around when I travel between my two home sites and elsewhere. Would just need to stash big monitors at each destination point. With 2GB, the new apparently maximum on that board, it's basically useless for the kind of 64-bit processing I need, or in fact any 64-bit real-life processing I can think of, and compared to other boards it'll need that bit of extra RAM it already has just to compensate for the extended space of the applications and operating system. When I look at that board with 64-bit eyes I simply see a severely RAM-constrained board, not useful for more than whatever any 32-bit small board could do as well as or better than the Pine. I have several small boards, as far as I can see the Pine won't outperform them on what such boards are useful for. I could be missing something, but I just can't see that it being 64-bit is a selling point. It's rather the opposite, in my opinion.)

I agree with Tor here - 64 bits is useful for machines with large physical memory, and the huge virtual address space can be useful for some security tactics, and 32-bit Windows was severely restricted so the move to 64 bits really helped there, but none of that applies to a small board. The x86 architecture was gretly improved with the invention of the AMD64 extensions, but again, here we have ARM and that situation doesn't apply.

I also don't see any sense in which learning to code on a 32 bit platform would in any way compromise a person's subsequent ability to code on a 64 bit platform. Genuine education - as opposed to training - gives a person understanding, and portable skills, and sets them up for all sorts of unexpected developments in the future.

Edit: if building a tablet or similar, given the bloat found in apps and browsers, it might be that 4G physical memory limit is a handicap. (Is it even true that 32 bit ARMs are in some way limited to 2G?) But again, this doesn't apply strongly to this kind of board.