https://forum.manjaro.org/t/manjaro-arm-19-02-released/75594

[fruitoftheloom]

https://forum.manjaro.org/t/manjaro-arm ... ased/75594

[Gavinmc42]

Aarch64, ARMv8 only?
64bit only OS's have been the writing on the wall for some time.
This one I have not tried, looks pretty.
Is it fast enough on a 3B+?

[Gavinmc42]

And Raspberry Pi 3 probably will never get GPU acceleration on mainline, because they don't contribute much of their code upstream.

No GPU acceleration?

[jamesh]

And Raspberry Pi 3 probably will never get GPU acceleration on mainline, because they don't contribute much of their code upstream.

No GPU acceleration?

Not quite sure what the guy is going on about. All the VC4 MESA stuff is going upstream IRC. And that is the HW acceleration.

[stuartiannaylor]

I think Ubuntu are threatening to do the same (32bit arm) and its sort of coming a norm.

With a hunch the Pi4 may herald a 64bit Raspbian but guess with newer products such as the Zero 32 bit Raspbian is very much here to stay.

Haven't heard anything about debian but that will be a big moment for Raspbian.

[fruitoftheloom]

https://forum.manjaro.org/t/manjaro-arm ... ased/75594

[stuartiannaylor]

I have been using Arch V7 and never tried the Aarch64 because I just didn't want to find out what "Use this installation only if you have no dependencies on the closed source vendor libraries shipped in the ARMv7 release"

I just presumed that would be quite a chunk of the Broadcom offerings, but like I say never bothered to find out.

I can not remember when Arch stopped X86 32 bit support but it was quite a while back maybe 2 years now.

I think the big question is what do you do with 32bit date/time and the 2038 problem that many seem to be answering by purely ditching 32bit

[hippy]

I think the big question is what do you do with 32bit date/time and the 2038 problem that many seem to be answering by purely ditching 32bit

We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.

[Gavinmc42]

We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.

I think it has more to do with the issue that code bloat is now so big that it is too hard to support 32bit cpus.
Too much testing and debugging?
Much easier just to stick with one architecture on ARM- Aarch64.

So what are these things driving the 64bit wagon?
Windows, Linux Desktops, Android, Chromium, Firefox and ?????
Gaming, AI, ML, NN?

Things have been getting more complex and supporting ARMv6/7 as well just add to the complexity.
Anyone using Chromium on a Pi B+? How fast does it run?

[jamesh]

We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.

I think it has more to do with the issue that code bloat is now so big that it is too hard to support 32bit cpus.
Too much testing and debugging?
Much easier just to stick with one architecture on ARM- Aarch64.

So what are these things driving the 64bit wagon?
Windows, Linux Desktops, Android, Chromium, Firefox and ?????
Gaming, AI, ML, NN?

Things have been getting more complex and supporting ARMv6/7 as well just add to the complexity.
Anyone using Chromium on a Pi B+? How fast does it run?

They just cannot be arsed to support it. Simple as. It requries double the testing because you are now running two different kernels. Its one of the reasons we still only have an official 32bit kernel - the support burden of the extra kernel.

As for driving the 64bit wagon, mainly rumour. There's not a huge difference in performance in the real world. But once people stop testing 32bit versions (e.g. Chromium?), then support for 32 falls away, so apps simply stop being updated, or even working.

Complexity of 32 and 64 is pretty much the same from a software point of view, any complexity increase is in the support.

[Gavinmc42]

They just cannot be arsed to support it.

What version is Chromium up to 72, 73?
Not sure how big their testing department is but something that big would be a pain to test?
And doing it 72 times for how many architectures?

Manjaro would have less developers than Google?
Lucky it is based on Arch, so others do some of the Kernel testing.
With everything so GUI, multicore cpu's are needed to get any decent speed.
And most Arm multi cores are A53 or higher now.

Manjaro would have to compile Chromium for a ARMv7 version to support it instead of just grabbing the binary?
Probably a trend, is Ubuntu dropping ARMv7? Hmm, smart, only do the server version?

Time to look at Minix3 on Pi's?

[hippy]

So what are these things driving the 64bit wagon?

IMO mostly hype and marketing, the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Since the arrival of 32-bit, memory bus width, instruction set width and internal register width have become increasingly conflated. Probably because, with 32-bit, there has been a correlation of the three in most implementations. There doesn't have to be, but most people now seem to believe there must.

There are benefits to 64-bit but I don't believe those are as great for most people as they are led to believe or imagine they will be.

What really drives 64-bit adoption is software which only works for 64-bit, giving the user no choice but going to 64-bit if they want to use the latest versions of that software. And that comes about through software developers deciding they will only support 64-bit.

[jahboater]

the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?

[rpdom]

the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?

Well, the simplest way seems obvious. Since you are dealing with 32-bit I/O, why address individual bytes? Address 32-bit words instead. That gives you 4 bytes per address and a maximum memory space of 16GB.

[jahboater]

the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?

Well, the simplest way seems obvious. Since you are dealing with 32-bit I/O, why address individual bytes? Address 32-bit words instead. That gives you 4 bytes per address and a maximum memory space of 16GB.

I used machines like that (mainframes) from 40+ years ago, and it was considered a nuisance then.
No way that would be acceptable now, especially with modern computer usage.

How do you implement "char *" efficiently?

[jamesh]

the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?

Using LPA addressing in the kernel gives access to 64GB of RAM overall using a 32 bit kernel, but indiviual processes are limited to 4GB.

If you want a process (ie program) to access more than 4GB, you need a 64bit kernel.

[hippy]

the spreading of the myth that one needs a 64-bit architecture to use larger memory sizes, that one can't access more than 4GB RAM without moving to a 64-bit architecture.

Without some kind of horrible address mapping thing in hardware, how can a 32-bit address access more than 4GB?

If you've got a 32-bit wide address bus then, no, it cannot access more than 4GB without mapping. But there's no reason the memory address bus width has to be 32-bit.

We accept that an 8-bit micro can handle numbers greater than 256, and can access more than 256 bytes of linear memory, so I don't see why it isn't obvious that this scales.

No, it's not as efficient as when memory address bus width, register width, data width are all the same but it does work and and doesn't need complex memory mapping, doesn't need any at all.

We would accept this would be fine on a 32-bit machine -

Code: Select all

uint32 adr = 0xFFFFFFFF;
uint32 num = 0x12345678;
*adr = num;

Why is it so hard to accept this would equally work for a 32-bit machine which had a 64-bit memory bus width ... ?

Code: Select all

uint64 adr = 0xFFFFFFFFFFFFFFF;
uint64 num = 0x123456789ABCDEF;
*adr = num;

It would equally work on an 8 or 16-bit machine providing that had a 64-bit memory bus width.

[plugwash]

Such an architecture could certainly be built in theory, but it would require substantially more instructions for every address calculation. Worse, for a modern pipelined CPU those instructions have tight dependencies on each other.

Given how cheap transistors are nowadays it makes little sense to widen the virtual addresses to 64 bits without also widening the data path to 64 bits.

[hippy]

Such an architecture could certainly be built in theory, but it would require substantially more instructions for every address calculation. Worse, for a modern pipelined CPU those instructions have tight dependencies on each other.

I absolutely agree with that. It's the belief that "it can't be done" which is wrong.

I would also say it's more than just theoretical. For hobbyists and those experimenting with FPGA's, even those writing pure software emulators, it is quite common to implement wide address buses and narrow data buses, even narrower instruction sets, because it keeps the internals simpler and external memory simpler and cheaper.

Given how cheap transistors are nowadays it makes little sense to widen the virtual addresses to 64 bits without also widening the data path to 64 bits.

I would tend towards agreeing with that, though the gain from widening the data bus and data paths isn't always as much as hoped for.

[hippy]

Well, the simplest way seems obvious. Since you are dealing with 32-bit I/O, why address individual bytes? Address 32-bit words instead. That gives you 4 bytes per address and a maximum memory space of 16GB.

I used machines like that (mainframes) from 40+ years ago, and it was considered a nuisance then.
No way that would be acceptable now, especially with modern computer usage.

It seems entirely acceptable with most architectures doing that. There are few other options with anything larger than an 8-bit data bus for memory if you get 32-bit or 64-bit data coming back from memory no matter what you would like to get.

How do you implement "char *" efficiently?

Hardware shifters and barrel rollers in the pipeline or somewhere before or after the ALU for input, read-update-write for output. This would also apply for "int *" or any case where the memory bus is wider than the data width being written.

If the memory itself physically allows byte, word and other sized writes the read-update-write can be optimised to just write the part which needs to be written with maybe a shift to get it into the right position.

Where the entity read or written spans memory addresses there will usually have to be two or more memory accesses if the instruction set allows unaligned access.

Which is an interesting aside. If dealing mostly with byte data an 8-bit memory bus may be better than larger, a 16-bit memory and bus better for short integers, 32-bits for longs. It's the old game of win some and lose some. What's gained in being able to read 64-bits in one hit means more complexity in writing 8-bit, unless one is prepared to keep 8-bit data in 64-bit data items. And vice-versa; easy to transfer smaller data items, more accesses needed for larger.

A programmer or a compiler doesn't need to worry about any of that, how it works. They just specify the instruction they are using and the size of data being read or written. It's up to the implementation inside a chip to sort it all out efficiently.

[stuartiannaylor]

I think the big question is what do you do with 32bit date/time and the 2038 problem that many seem to be answering by purely ditching 32bit

We really need to put an end to this persistent and pervasive myth that 64-bit data or 64-bit addressable memory can only be used by 64-bit architectures.

There is no myth in the 32 bit 2038 in the Linux kernel.
x32 ABI was a sort of 32->64bit bridge and its been depreciated and yeah sure you could rewrite your own kernel.

The kernel is going all 64bit as those methods are not deemed worthwhile supporting so those of us on 32 bit have a 2038 problem as you can be pretty sure the above methods are never going to be supported.
It doesn't matter that it could be capable what matters is what is available and 64bit datetime is not going to be available probably because it would be a huge undertaking to employ something more than single register vs single register compares and that a 32bit system handing 64 bit is twice as slow as each 64 bit number has to be loaded in 2 32 bit chunks.

From Linus Torvalds <>
Date Mon, 10 Dec 2018 17:40:33 -0800
Subject Re: Can we drop upstream Linux x32 support?
share

On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux. Here are some problems with it:

I talked to Arnd (I think - we were talking about all the crazy ABI's,
but maybe it was with somebody else) about exactly this in Edinburgh.

Apparently the main real use case is for extreme benchmarking. It's
the only use-case where the complexity of maintaining a whole
development environment and distro is worth it, it seems. Apparently a
number of Spec submissions have been done with the x32 model.

I'm not opposed to trying to sunset the support, but let's see who complains..

Linus

So whatever you believe there is no solution to 32bit 2038 apart from a 64bit kernel and device.

[plugwash]

There is no myth in the 32 bit 2038 in the Linux kernel.

It's not a myth, but it's not an insurmountable problem either.

x32 ABI was a sort of 32->64bit bridge and its been depreciated

x32 was an attempt at making an ABI which ran the processor in 64 bit mode but had 32 bit pointers, as you say it didn't catch on.

The kernel is going all 64bit

You seem to be taking a post about dropping an obscure feature as evidence of the kernel dropping 32 bit support in general. That seems like rather a leap.

So whatever you believe there is no solution to 32bit 2038 apart from a 64bit kernel and device.

On the contrary 64 bit time on 32 bit systems is being worked on. It's not fundamentally much different from the way large file support was added years ago. It's taking time because it's not top of too many peoples priority list yet and because it needs to be done without breaking existing software.

https://lwn.net/Articles/776435/

[hippy]

There is no myth in the 32 bit 2038 in the Linux kernel.

No there's no myth there. The overflow of the 32-bits currently used is there, is going to happen, and will cause problems when it does if not resolved. It's as real as Y2K was. No one's denying that, no one's calling that a myth.

Just changing 'elapsed time since epoch' to a 64-bit integer would solve the root problem.

That has knock-on issues for anything which uses that, and anything which does has to be updated as well. And that likely creates further knock-on problems.

None of that however requires moving to a 64-bit architecture, a matching 64-bit OS and kernel though.

So whatever you believe there is no solution to 32bit 2038 apart from a 64bit kernel and device.

There may be no solution which Linus or some others are willing to provide but I am sure third parties will.

One can even stick with a uint32 number, simply offset 2038 back to 2008, fiddle with things to make that rewind invisible and have things usable for most people, even if not perfect.

I guess we'll just have to wait and see.

[plugwash]

Umm why are you quoting something I quoted and debunked as if I said it?

[jamesh]

Umm why are you quoting something I quoted and debunked as if I said it?

Looks like the wrong quote markup was edited in. If OP doesn't fix it go ahead and fix it yourself.