RPI4: Why is everything still 32-bit?

[Moonmarch]

The RPI computer is not the same as the Google Android platform, because Google sells hardware that costs over $100, the RPI computers will cost at least $100 the RPI4 4GB starter kit which means developing the RPI platform will be slow regardless of how many hardware units are being sold if the RPI computers do no meet your expectations which includes playing DOTA 2 using Steam or 1080P 60 FPS video on YouTube you will be in for a real surprise, the RPI computer is not this money magnet that convinces the public the RPI computer can run everything including x64 software, you can say Android uses programs that use the ARM CPU you have to take into consideration Android is not a desktop Android is more of a all in one computer, phone , or tablet operating system.

If 64 bit operating systems are important or if you are interested in contributing to the development of a 64 bit OS that is usable on the RPI4 computer you can install the Manjaro Linux ARM OS here is a link to a video on how to install the OS:

Manjaro Arm Raspberry Pi 4 Full Install / SetUp Guide:
https://youtu.be/ozAWczLqsB4

[ejolson]

It seems reasonable to me that they should run 64-bit programs!

What did you not understand with:
"It is designed to be an education and tinkering low cost SOC based computer.

Yet that low-cost buys you a 1500MHz quad-64-bit processor with 1000-4000 MB of memory and with dozens of 64-bit registers. It is a very powerful machine (the first one I wrote compilers on and for was 2.5MHz, 8-bit with 0.016MB memory).

It what way would it break compatibility? Is ARM64 different from x64 in that a processor executing in 64-bit mode cannot also be running 32-bit binaries? Does it need to be all-32-bit or all-64-bit for every piece of software?

Almost everyone running Linux on an Intel-compatible desktop computer had to replace the vendor-supported Windows operating system with one of the many well-supported Linux distributions. While you can buy servers with vendor-support for Linux, around here it is not uncommon to replace the preinstalled Linux image before deployment.

The Raspberry Pi is popular enough that many standard Linux distributions have direct support for it. There are also more customized images, such as the above mentioned 64-bit Gentoo that work well.

In addition to reverse compatibility, I suspect another reason Raspbian has remained 32-bit is the fact that Python runs about 20% slower on the Pi when compiled for the ARM 64-bit architecture. Although this slowdown appears to be peculiar to Python, it is also true that one of the main uses for the Pi is teaching Python programming.

[rin67630]

Has someone got a feeling on how many Pi users really need increased performance?
Most of the users, who use the Pi for education, programming and tinkering (as it should be) will probably use a Pi 3B+ at no more than 20%, am I wrong?
You may use it for multimedia purposes, which is possible, but that is IMHO not for what it should be optimized.
OK, the browser is awfully slow, but who, from the above mentioned users, really cares?

[ejolson]

Has someone got a feeling on how many Pi users really need increased performance?
Most of the users, who use the Pi for education, programming and tinkering (as it should be) will probably use a Pi 3B+ at no more than 20%, am I wrong?
You may use it for multimedia purposes, which is possible, but that is IMHO not for what it should be optimized.
OK, the browser is awfully slow, but who, from the above mentioned users, really cares?

The fact that the 4GB version of Pi 4B is so popular attests to how many people care about better performance.

In terms of supporting computer-literacy based curriculum reform, because of the amount of information on Stack Overflow, this and other websites, it is difficult to teach programming using a computer that doesn't have a fast web browser.

With regard to what people need, my understanding is that the essentials are food, shelter, water and a Pi Zero.

[Heater]

ejolson,

In terms of supporting computer-literacy based curriculum reform, because of the amount of information on Stack Overflow, this and other websites, it is difficult to teach programming using a computer that doesn't have a fast web browser.

That is a rather fundamental point now a days.

Back in the day the first generation of kids to learn programming ever had the computer and the manual that came with it. I'm talking about the C64, BBC Micro, Sinclair Spectrum era. The golden age of personal computing.

Contrast with today. For example I have been learning the Rust language recently. It would be impossible to make any progress without a net access and a decent web browser.

[LTolledo]

....with regard to what people need, my understanding is that the essentials are food, shelter, water and a Pi Zero....

...and all the while I've always thought the last one was "smart phone", instead of Pi Zero
...am maybe getting "old" faster than I think I am...

[jdonald]

after doing 'rpi-update', it rebooted so that 'uname -a' reports 'aarch64'.

However, 'getconf LONG_BIT' reported '32'. But then, 'lscpu' says 'aarch64'. gcc however still compiles to 32-bits, and there doesn't seem to be a way to update it. A newly downloaded tcc said its '-m64' option was not implemented.

Follow these instructions to get a 64-bit environment--or use raspbian-nspawn-64 mentioned above--before installing tcc. (Manjaro or Gentoo won't give you APT if that's the package manager you prefer.)

Code: Select all

(pi64)[email protected]:~ $ getconf LONG_BIT
64
(pi64)[email protected]:~ $ tcc -m64 hello.c
(pi64)[email protected]:~ $ file a.out
a.out: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, stripped

Will this kernel run a 64-bit ELF executable as a 64-bit process? Will there be a 64-bit libc_so.6 library? If so, then eventually I can wrote ELFs directly and don't need to care about anything else, but for now I need to rely on existing tools like gcc, as and tcc.

Yes & yes. You can generate aarch64 ELFs that run directly on 32-bit Raspbian userland + aarch64 kernel (cf. gcc -static -static-libgcc).

there is no reason why code should not be compilable on 32 or 64 bit machines. Just write architecture independent code

OP is writing and maintaining his/her own compiler, so it's not that simple.

[sal55]

so simply just boils down to:

1. stop whining and contribute to the development of 64-bit OS for Raspberry Pi

2. stop whining and wait for 64-bit OS (or your choice) to be available when its available

3. stop whining

or, if impatience sets it... you can always build your own and not rely on (the charity of) others.

These days I work on hobbyist language stuff like compilers and interpreters. One of my languages is a neat alternative to C. It would have been nice to make them work on the RPi machines (but my work there is hampered by not liking to work on Linux or grapple with X11).

But that's what I do; I don't write OSes (I've done enough of that stuff in the past when you had do all the programming involved for GUI apps on non-graphical OSes or it might have been a bare machine with no software at all).

Is it whining when someone buys a machine advertised as having a "64-bit processor" but in reality everything is 32-bit unless you download experimental 64-bit versions that may or may not work. (I paid extra for my machine because it came with everything needed to be up and running immediately, except the included SD card with the promised OS was blank!)

If I'd known it was a work in progress, I probably wouldn't have bothered, or gone for something else.

(I've just spent 2-3 hours trying to use Ubuntu-mate/aarch64 from one of the raspberry-pi 3rd party links. With most of that spent taking apart my PC's sd card reader, which saw every card as write-protected, then soldering in a by-pass for the switch. (Using the Etcher s/w on a laptop, that didn't work.) But when the card image was finally written, it was dead on the RPi4. At present only Gentoo offers a test path.

And 2-3 hours before that trying to see if my software could work with a 32-bit target, but too many subtle issues, and it would be a backwards step. All an interesting diversion, but I think I'll step back from this whole project.)

[jdonald]

I've just spent 2-3 hours trying to use Ubuntu-mate/aarch64 ... At present only Gentoo offers a test path.

Did you miss my post? It's right above yours and the point is you should use the arm_64bit Raspbian you already configured.

Or Moonmarch suggested Manjaro, but it sounds like you're now in a situation where it's hard to write a new SD card.

[ejolson]

Is it whining when someone buys a machine advertised as having a "64-bit processor" but in reality everything is 32-bit unless you download experimental 64-bit versions that may or may not work. (I paid extra for my machine because it came with everything needed to be up and running immediately, except the included SD card with the promised OS was blank!)

My recollection is that 64-bit capable Intel-compatible computers shipped with 32-bit versions of Windows for many years. I don't think very many people worried about that or felt any more cheated than usual. As far as experimental goes, Linux supported 64-bit processors long before Windows and has officially supported 64-bit ARM since late 2012. It is, therefore, not surprising that 64-bit Linux is quite stable on all 64-bit capable versions of Raspberry Pi including the latest 4B.

In a way, all open-source software is experimental. On the other hand, open-source does not mean developed by unpaid volunteers as a hobby. Many kernel developers are regular employees of various computer companies. There is further evidence that the widespread public auditability of Linux kernel has led to code that is best-in-class, especially when compared to closed source efforts. Another aspect related to the stability of Linux is attributable to the effective and practical way in which Linus has managed the project.

I'm sorry the SD card you purchased was blank. There have already been a number of reasonable suggestions how to get a 64-bit Linux development environment up and running on the Raspberry Pi. While you seem close to successfully doing this, the wrong turns along the way have apparently been quite frustrating. It's possible that some of your trouble could be related to a lack of experience with Linux in general. My experience is that after a few difficulties the learning curve flattens out quite quickly and further progress is much easier.

[W. H. Heydt]

The fact that the 4GB version of Pi 4B is so popular attests to how many people care about better performance.

I am probably rather old and jaded, but I think the popularity of the Pi4B4 has more to with people not knowing how to judge how much machine is enough for what they want to do than any actual need or desire for better performance.

While I do have a project that is going to be put on three Pi4B4 boards (main, hot backup/replicated DB, plus a test system), for most of my other Pi4B plans I will probably use Pi4B2 boards. All of this is at least somewhat consistent, in that I have 2 Pi4B2, 1 Pi4B1, and 1 Pi4B4 so far.

[graphicw]

I just bought a 64-bit RPI4 to supercede my RPI1 from 2012 or so. I wanted to port my 64-bit language tools to it.

After quite a lot of preliminary work on a PC, I then discovered that the Raspbian I was using was a 32-bit system!

I'd like to ask what the point is of selling a 64-bit machine (quad 64-bit even) when most software that goes with it is still 32-bit? I understand the RPi has been 64-bit from at least RPI3 too.

From looking around, there appear to be some half-finished 64-bit OSes. I just tried Gentoo, but compared with Raspbian (which makes the RPi4 look like a PC almost) it's rather poor. (Strange behaviour with USB drives; 'apt-get' command apparently missing).

I also had a go at Ubuntu, but the article that described the early version omitted to provide a login name and password (but that is not a GUI version, which is needed to mitigate the problem of HDMI overscanning that affects all OSes I've tried, and is completely immune to config changes or fixes).

So, any news of when a full 64-bit OS might be stable? If it's a year, fine, I'll send this RPI4 back or put it on the shelf, but I just wished this was properly advertised.

FIrst off, Gentoo is not Debian based, so there will not be "apt" or "apt-get". Raspbian will probably be 32 bit for quite a while. That does not mean you are out of options with your Raspberry Pi 4. Ubuntu Mate is in the works and will most likely be 64 bit since the previous versions are; it is also Debian based meaning "apt-get" will be available. I doubt it will be a whole year before Ubuntu Mate is ready, I believe it will be more like several months. I do not advise that you attempt to install Ubuntu on your Pi 4 as you lack the experience to deal with the problems that will need to be overcame to make it workable. It is best to stick with Raspbian in your case for the time being and wait for the official release of Ubuntu Mate. The Pi 4 is still very early in it's life cycle and there will soon be far more available for it. Patience is of virtue as everything will be sorted in due time.

[Milliways]

Recent PIs have been advertised as using 64-bit processors.

Another thing you do not seem to understand is the difference between Marketing and Engineering.

Marketing is the bane of the Engineering department (and I am sure vice versa, if the number of times Marketing complained to the Board about me is indicative).

[ejolson]

Recent PIs have been advertised as using 64-bit processors.

Another thing you do not seem to understand is the difference between Marketing and Engineering.

Marketing is the bane of the Engineering department (and I am sure vice versa, if the number of times Marketing complained to the Board about me is indicative).

The 3B, 3B+ and 4B really do have 64-bit processors and there are many choices of 64-bit Linux distributions which run on them. I've been switching a 64-bit Gentoo SD card back and forth between a Pi 3B+ and a 4B and it works great in either one.

From a marketing versus engineering point of view, it is notable that the data bus to main memory on the Raspberry Pi is 32-bits wide. This means that a 64-bit pointer, for example, takes two memory cycles to fetch from RAM rather than only one. Although all 64-bit software continues to work fine, tuning that software for optimal performance on the Pi is likely quite different than tuning for a Cavium ThunderX2, Fujitsu A64FX or even an Annapurna Graviton server processor.

[rpdom]

From a marketing versus engineering point of view, it is notable that the data bus to main memory on the Raspberry Pi is 32-bits wide. This means that a 64-bit pointer, for example, takes two memory cycles to fetch from RAM rather than only one.

I haven't looked at 64-bit ARM code so far. Are the instructions 64 bits as well? If so, it will take two cycles to load each instruction instead of one for each 32-bit instruction (or two 16-bit instructions when running in Thumb mode).

[Heater]

sal55,

Recent PIs have been advertised as using 64-bit processors.

Really, where?

I don't even see the number 64 appearing here:

https://www.raspberrypi.org/

https://www.raspberrypi.org/products/ra ... 4-model-b/
https://www.raspberrypi.org/downloads/raspbian/

It is buried away in the tech spec:
https://www.raspberrypi.org/products/ra ... fications/

But that is not advertising.

[rpdom]

sal55,

Recent PIs have been advertised as using 64-bit processors.

Really, where?

I don't even see the number 64 appearing here:

https://www.raspberrypi.org/

https://www.raspberrypi.org/products/ra ... 4-model-b/
https://www.raspberrypi.org/downloads/raspbian/

It is buried away in the tech spec:
https://www.raspberrypi.org/products/ra ... fications/

But that is not advertising.

Here: https://www.raspberrypi.org/blog/raspbe ... w-from-35/ ?

Here are the highlights:

A 1.5GHz quad-core 64-bit ARM Cortex-A72 CPU (~3× performance)

Personally I'm quite happy with a 32-bit OS for now. The 100% compatibility with my older systems is very important to me.

If anything I'd rather have my laptop running Raspberry Pi Debian PC Desktop (Hey, that sounds like a neater name for it than others that have been used) upgraded to 64-bit than my Raspbian installs.

[Heater]

That blog clearly says "1.5GHz quad-core 64-bit ARM Cortex-A72 CPU". Which is of course true.

It says nothing about 32bit vs 64 bit OS.

Except, in answer to one of the first comments there it clearly says "no" to 64 bit.

Hardly what I would call "advertising".

[rpdom]

But you said you don't see the number "64" anywhere. I pointed out it was mentioned. I didn't say anything about the OS.

Personally I think someone should create a 42-bit CPU, but that's an infinite improbability.

[Heater]

That 64 is not in the obvious places one looks for advertising.

And another thing... The Pi, as sold, out of the box, does not have an operating system. As far as I know all the available operating systems for the Pi are community projects. Do correct me if I'm wrong.

[jamesh]

From a marketing versus engineering point of view, it is notable that the data bus to main memory on the Raspberry Pi is 32-bits wide. This means that a 64-bit pointer, for example, takes two memory cycles to fetch from RAM rather than only one.

The link the the RAM itself is indeed 32bits wide, but this is a massive oversimplification of how accesses are made - which are usually 128bit bursts IIRC. It's really not as simple as saying "it takes two memory cycles".

[hippy]

I haven't looked at 64-bit ARM code so far. Are the instructions 64 bits as well? If so, it will take two cycles to load each instruction instead of one for each 32-bit instruction (or two 16-bit instructions when running in Thumb mode).

I haven't looked either, but the common practice is to keep instructions the same size, just increase the register and data size.

So the only instructions which extend across multiple 32-bits should be load immediates, those with large index offsets, extended or CISC instructions. And that's also how it is for a 32-bit CPU with a 32-bit instruction when loading immediates which can't be packed into a bit field within the instruction itself.

Some 32-bit CPU's will not have 32-bit immediates; require two consecutive 32-bit instructions with 16-bit data to load upper and lower halves - same result but often easier to implement. 64-bit CPU's may require four such instructions, but if the immediate field is more than 16-bit fewer instructions are needed.

Some ISA's may dedicate 'half of all instructions' to being immediates, and through using sign extension can have most 64-bit loads as two 32-bit instructions, fewer cases will require three 32-bit instructions.

There are gains from 64-bit but I would consider 64-bit mostly over-rated. One won't get a doubling of performance, and it may be barely noticeable in practice for most things.

To me the clamour for 64-bit is a lot like demanding the 300mph car because 'it's better than the 200mph car', when 100mph is good enough for most people.

Personally I think someone should create a 42-bit CPU, but that's an infinite improbability.

You can easily roll your own 42-bitter with a RISC-V implementation though you won't be able to label it "RISC-V".

I doubt any general purpose non-power-of-two-bits machine is going to put in an appearance any time soon but it's the sort of thing embedded people may create for specific tasks.

[rpdom]

I haven't looked either, but the common practice is to keep instructions the same size, just increase the register and data size.

Lol!

Look at x86 with 8, 16, 24, 32 and more instruction sizes.

ARM started with 32 bit instructions. Later came Thumb with a reduced 16 bit instruction set for speed.

I doubt any general purpose non-power-of-two-bits machine is going to put in an appearance any time soon

I spent many years working on 36-bit systems.

[PeterO]

I spent many years working on 36-bit systems.

It would be remiss of me not to mention that I still maintain and use a 39 bit machine. It may be in a museum, but it still counts (Pun intended )
PeterO

[davidcoton]

Personally I think someone should create a 42-bit CPU, but that's an infinite improbability.

That is obviously the answer to everything. 1024 times better than 32-bit, though not quite as "good" as 64-bit.