Pi 4, 8GB RAM, 64-bit OS...

That is excellent news.

I wonder if it also includes the necessary assemblers and compilers to produce 64 bit programs?

IMHO this will be computing coming of age for the man on the Clapham Omnibus, for no longer will it be necessary to program one's way around the limitations of processor design because with so much memory, take the same design principle that made Admiral Fisher's Dreadnought battleship design so capable, big guns only, make all storage, even for

8 bit bytes, 64 bits.

64-bit-only BCPL anybody?

PS ! ! ! !

Not forgetting that all instructions encode into 32 bits, so a compiler based on 64 bit data alone will be struggling to output dollops of 32 bits, perhaps a variation of the PEEK and POKE so favoured by early domestiv BASICs?

Likely when in a few months the 64-bit OS becomes stable.

64-bit BCPL has been a thing for a long time. Just re-compile the compiler and you'll have it. Should take all of a second or so.

-Gordon (BCPL user, but sticking to 32-bit on a 16 bit CPU with an 8-bit memory bus, for now :-)

BCPL compiles into a bytecode. This is then interpreted by a C program (at least on most modern Unix/Linux systems).

There is a native ARM code generator but I've never looked at it.

-Gordon

It should. I've run 64-bit Gentoo Linux on the Raspberry Pi 3 before. Compiling on-device can be a bit painful (and some of the larger packages, like Chromium, won't build in 1 GB RAM), but I would build software under emulation on a more powerful host and sync binary packages over for installation.

_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(

Top-posting! \_^_/ >What's the most annoying thing on Usenet?

Interesting.

Did the foreign Gentoo Linux provide full video capability and access to all the I/O?

I'm afraid this makes no sense at all. Both ARMv7 (32 bit) and ARMv8 (ARMv8) can handle data of 8, 16, 32, and 64 bit widths.

---druck

It makes perfect sense in the context of the discussion about a Dreadnought language that has ONLY 64 bit variables.

Indeed.

Although I'm not sure I'd describe BCPL as "Dreadnought" - more "light cruiser" :-)

And now I'm thinking - does the Piv4 (and v3) have a 64-bit data bus, or does it need 2 memory cycles at 32-bit each to read a 64-bit value. I'd like to think it has a 64-bit (or wider) databus, but I really don't know.

This is something that's making my retro implementation of BCPL on a

65816 somewhat slower than it might be - the '816 is touted as a 16 bit CPU, but it's still locked into an 8-bit data bus.

Gordon

No, its still gibberish. BASIC and C running on 8 bit machines could have 32 bit variables. Having the size of the variable match the size of the processors register size is the most efficient combinations, but it in no way precludes using larger (or smaller) variables in any language.

---druck

That was the problem on 8 bit micros with C - the language guarantees a

16 bit integer minimum.

even multiplying 8 x 8 bits meant promotion to 16 and a 16 bit result

--
"When one man dies it's a tragedy. When thousands die it's statistics." 

Josef Stalin

I think that you have missed the point being made and are arguing off at a tangent.

All Pis still have a 32 bit wide external DRAM interface, so that aspect doesn't change, although it goes from LPDDR2 to LPDDR4 on the Pi 4 (so higher memory bandwidth).

That will feed the last-level cache. That's shared with the GPU and I'm not sure if details are public, but as far as the CPU is concerned: (cut and paste from Arm's descriptions)

Pi 2 v1.0: Cortex A7 Fixed [L2 cache] line length of 64 bytes [512 bits] The L2 memory system interfaces with an AMBA AXI Coherency Extension (ACE) interconnect on a 128-bit wide bus.

Pi 3: Cortex A53

512 bit wide fetch path from L2 A single 128-bit wide master interface to external memory

Pi 4: Cortex A72 Fixed [L2 cache] line length of 64 bytes [512 bits] Configurable 128-bit wide ACE or 128-bit wide CHI interface [to external memory]

The description of the Pi 1's ARM1176 is confusing as it appears the L2 has four separate downstream ports, three 64 bit and one 32 bit. However I think the best you could do is 64 bit fetches.

So no change across the Pi families, possibly excepting the Pi 1. As far as the CPU core is concerned you can make 32, 64 or 128 bit accesses from cache in a single cycle. The bottom of the L2 can make 128 bit wide requests from DDR memory, which will cause a burst of four 32 bit requests back-to-back. The Pi 4 has LPDDR4-3200, which means those 4 requests will take:

4*(1/(3200*10^6)) = 1.25ns

Generally the setup time for a DRAM is the expensive part, so once you have the request in the extra cycles for fetching multiple words don't cost much more.

(I can't seem to find the data sheet for the Pi 4's DRAM part to see what the initial latency is)

But you'll presumably win with not burning lots of cycles doing 32 bit arithmetic. Although lack of registers will likely be a pain.

Theo

Some interesting details in this thread, look for posts by dom especially:

Got everything working I tried (SAMBA, NTP, SNMP, minicom etc.) and installed gpsd from the source (as I wanted the current 3.20, not the "ancient" 3.20). Minor issue to get my own gps monitoring software working - write-up here:

RPi 4B, 4 GB. Fast command-line compiles etc. Noted that the serial port changed from ttyAMA0 to ttyS0.

--
Cheers, 
David 
Web: http://www.satsignal.eu

What is the primary and secondary uart changed between the pi 1/2 and 3/4. ttyS0 was and is the mini-uart, you might not want to use that, or at least it requires fixing the cpu with core_freq=250. See

Yes, I had forgotten about the mini/PL011 UART issue, not even following my own notes! Thanks for the reminder - I've updated my Web page and thanked you there.

--
Cheers, 
David 
Web: http://www.satsignal.eu