64-bit embedded computing is here and now

Sometimes things move faster than expected.
As someone with an embedded background this caught me by surprise:

Tera-Byte microSD cards are readily available and getting cheaper.
Heck, you can carry ten of them in a credit card pouch.
Likely to move to the same price range as hard disks ($20/TB).

That means that a 2+ square inch PCB can hold a 64-bit processor and enough storage for memory mapped files larger than 4GB.

Is the 32-bit embedded processor cost vulnerable to 64-bit 7nm devices as the FABs mature? Will video data move to the IOT edge? Will AI move to the edge?  Will every embedded CPU have a built-in radio?

Wait a few years and find out.

On 6/7/2021 7:47 AM, James Brakefield wrote:
> 
> Sometimes things move faster than expected. As someone with an embedded
> background this caught me by surprise:
> 
> Tera-Byte microSD cards are readily available and getting cheaper. Heck, you
> can carry ten of them in a credit card pouch. Likely to move to the same
> price range as hard disks ($20/TB).
> 
> That means that a 2+ square inch PCB can hold a 64-bit processor and enough
> storage for memory mapped files larger than 4GB.

Kind of old news.  I've been developing on a SAMA5D36 platform with 256M of
FLASH and 256M of DDR2 for 5 or 6 years, now.  PCB is just over 2 sq in
(but most of that being off-board connectors).  Granted, it's a 32b processor
but I'll be upgrading that to something "wider" before release (software and
OS have been written for a 64b world -- previously waiting for costs to fall
to make it as economical as the 32b was years ago; now waiting to see if I
can leverage even MORE hardware-per-dollar!).

Once you have any sort of connectivity, it becomes practical to support
files larger than your physical memory -- just fault the appropriate
page in over whatever interface(s) you have available (assuming you
have other boxes that you can talk to/with)

> Is the 32-bit embedded processor cost vulnerable to 64-bit 7nm devices as
> the FABs mature? Will video data move to the IOT edge? Will AI move to the
> edge?  Will every embedded CPU have a built-in radio?

In my case, video is already *at* the edge.  The idea of needing a
"bigger host" or "the cloud" is already obsolescent.  Even the need
for bulk storage -- whether on-board (removable flash, as you suggest)
or remotely served -- is dubious.  How much persistent store do you
really need, beyond your executables, in a typical application?

I've decided that RAM is the bottleneck as you can't XIP out of
an SD card...

Radios?  <shrug>  Possibly as wireless is *so* much easier to
interconnect than wired.  But, you're still left with the power
problem; even at a couple of watts, wall warts are unsightly
and low voltage DC isn't readily available *everywhere* that
you may want to site a device.  (how many devices do you
want tethered to a USB host before it starts to look a mess?)

The bigger challenge is moving developers to think in terms of
the capabilities that the hardware will afford.  E.g., can
you exploit *true* concurrency in your application?  Or, will
you "waste" a second core/thread context on some largely
decoupled activity?  How much capability will you be willing
to sacrifice to your hosting OS -- and what NEW capabilities
will it 0provide you?

> Wait a few years and find out.

The wait won't even be *that* long...

James Brakefield <jim.brakefield@ieee.org> writes:
> Is the 32-bit embedded processor cost vulnerable to 64-bit 7nm devices
> as the FABs mature? Will video data move to the IOT edge? Will AI move
> to the edge?  Will every embedded CPU have a built-in radio?

I don't care what the people say--
32 bits are here to stay.

On 08/06/2021 07:31, Paul Rubin wrote:
> James Brakefield <jim.brakefield@ieee.org> writes:
>> Is the 32-bit embedded processor cost vulnerable to 64-bit 7nm devices
>> as the FABs mature? Will video data move to the IOT edge? Will AI move
>> to the edge?  Will every embedded CPU have a built-in radio?
> 
> I don't care what the people say--
> 32 bits are here to stay.
> 

8-bit microcontrollers are still far more common than 32-bit devices in
the embedded world (and 4-bit devices are not gone yet).  At the other
end, 64-bit devices have been used for a decade or two in some kinds of
embedded systems.

We'll see 64-bit take a greater proportion of the embedded systems that
demand high throughput or processing power (network devices, hard cores
in expensive FPGAs, etc.) where the extra cost in dollars, power,
complexity, board design are not a problem.  They will probably become
more common in embedded Linux systems as the core itself is not usually
the biggest part of the cost.  And such systems are definitely on the
increase.

But for microcontrollers - which dominate embedded systems - there has
been a lot to gain by going from 8-bit and 16-bit to 32-bit for little
cost.  There is almost nothing to gain from a move to 64-bit, but the
cost would be a good deal higher.  So it is not going to happen - at
least not more than a very small and very gradual change.

The OP sounds more like a salesman than someone who actually works with
embedded development in reality.

On 6/7/2021 10:59 PM, David Brown wrote:
> 8-bit microcontrollers are still far more common than 32-bit devices in
> the embedded world (and 4-bit devices are not gone yet).  At the other
> end, 64-bit devices have been used for a decade or two in some kinds of
> embedded systems.

I contend that a good many "32b" implementations are really glorified
8/16b applications that exhausted their memory space.  I still see lots
of designs build on a small platform (8/16b) and augment it -- either
with some "memory enhancement" technology or additional "slave"
processors to split the binaries.  Code increases in complexity but
there doesn't seem to be a need for the "work-per-unit-time" to.

[This has actually been the case for a long time.  The appeal of
newer CPUs is often in the set of peripherals that accompany the
processor, not the processor itself.]

> We'll see 64-bit take a greater proportion of the embedded systems that
> demand high throughput or processing power (network devices, hard cores
> in expensive FPGAs, etc.) where the extra cost in dollars, power,
> complexity, board design are not a problem.  They will probably become
> more common in embedded Linux systems as the core itself is not usually
> the biggest part of the cost.  And such systems are definitely on the
> increase.
> 
> But for microcontrollers - which dominate embedded systems - there has
> been a lot to gain by going from 8-bit and 16-bit to 32-bit for little

I disagree.  The "cost" (barrier) that I see clients facing is the
added complexity of a 32b platform and how it often implies (or even
*requires*) a more formal OS underpinning the application.  Where you
could hack together something on bare metal in the 8/16b worlds,
moving to 32 often requires additional complexity in managing
mechanisms that aren't usually present in smaller CPUs (caches,
MMU/MPU, DMA, etc.)  Developers (and their organizations) can't just
play "coder cowboy" and coerce the hardware to behaving as they
would like.  Existing staff (hired with the "bare metal" mindset)
are often not equipped to move into a more structured environment.

[I can hack together a device to meet some particular purpose
much easier on "development hardware" than I can on a "PC" -- simply
because there's too much I have to "work around" on a PC that isn't
present on development hardware.]

Not every product needs a filesystem, network stack, protected
execution domains, etc.  Those come with additional costs -- often
in the form of a lack of understanding as to what the ACTUAL
code in your product is doing at any given time.  (this isn't the
case in the smaller MCU world; it's possible for a developer to
have written EVERY line of code in a smaller platform)

> cost.  There is almost nothing to gain from a move to 64-bit, but the
> cost would be a good deal higher.

Why is the cost "a good deal higher"?  Code/data footprints don't
uniformly "double" in size.  The CPU doesn't slow down to handle
bigger data.

The cost is driven by where the market goes.  Note how many 68Ks found
design-ins vs. the T11, F11, 16032, etc.  My first 32b design was
physically large, consumed a boatload of power and ran at only a modest
improvement (in terms of system clock) over 8b processors of its day.
Now, I can buy two orders of magnitude more horsepower PLUS a
bunch of built-in peripherals for two cups of coffee (at QTY 1)

>  So it is not going to happen - at
> least not more than a very small and very gradual change.

We got 32b processors NOT because the embedded world cried out for
them but, rather, because of the influence of the 32b desktop world.
We've had 32b processors since the early 80's.  But, we've only had
PCs since about the same timeframe!  One assumes ubiquity in the
desktop world would need to happen before any real spillover to embedded.
(When the "desktop" was an '11 sitting in a back room, it wasn't seen
as ubiquitous.)

In the future, we'll see the 64b *phone* world drive the evolution
of embedded designs, similarly.  (do you really need 32b/64b to
make a phone?  how much code is actually executing at any given
time and in how many different containers?)

[The OP suggests MCus with radios -- maybe they'll be cell phone
radios and *not* wifi/BLE as I assume he's thinking!  Why add the
need for some sort of access point to a product's deployment if
the product *itself* can make a direct connection??]

My current design can't fill a 32b address space (but, that's because
I've decomposed apps to the point that they can be relatively small).
OTOH, designing a system with a 32b limitation seems like an invitation
to do it over when 64b is "cost effective".  The extra "baggage" has
proven to be relatively insignificant (I have ports of my codebase
to SPARC as well as Atom running alongside a 32b ARM)

> The OP sounds more like a salesman than someone who actually works with
> embedded development in reality.

Possibly.  Or, just someone that wanted to stir up discussion...

On 08/06/2021 09:39, Don Y wrote:
> On 6/7/2021 10:59 PM, David Brown wrote:
>> 8-bit microcontrollers are still far more common than 32-bit devices in
>> the embedded world (and 4-bit devices are not gone yet).  At the other
>> end, 64-bit devices have been used for a decade or two in some kinds of
>> embedded systems.
> 
> I contend that a good many "32b" implementations are really glorified
> 8/16b applications that exhausted their memory space.  

Sure.  Previously you might have used 32 kB flash on an 8-bit device,
now you can use 64 kB flash on a 32-bit device.  The point is, you are
/not/ going to find yourself hitting GB limits any time soon.  The step
from 8-bit or 16-bit to 32-bit is useful to get a bit more out of the
system - the step from 32-bit to 64-bit is totally pointless for 99.99%
of embedded systems.  (Even for most embedded Linux systems, you usually
only have a 64-bit cpu because you want bigger and faster, not because
of memory limitations.  It is only when you have a big gui with fast
graphics that 32-bit address space becomes a limitation.)

A 32-bit microcontroller is simply much easier to work with than an
8-bit or 16-bit with "extended" or banked memory to get beyond 64 K
address space limits.

> 
>> We'll see 64-bit take a greater proportion of the embedded systems that
>> demand high throughput or processing power (network devices, hard cores
>> in expensive FPGAs, etc.) where the extra cost in dollars, power,
>> complexity, board design are not a problem.  They will probably become
>> more common in embedded Linux systems as the core itself is not usually
>> the biggest part of the cost.  And such systems are definitely on the
>> increase.
>>
>> But for microcontrollers - which dominate embedded systems - there has
>> been a lot to gain by going from 8-bit and 16-bit to 32-bit for little
> 
> I disagree.  The "cost" (barrier) that I see clients facing is the
> added complexity of a 32b platform and how it often implies (or even
> *requires*) a more formal OS underpinning the application.

Yes, that is definitely a cost in some cases - 32-bit microcontrollers
are usually noticeably more complicated than 8-bit ones.  How
significant the cost is depends on the balances of the project between
development costs and production costs, and how beneficial the extra
functionality can be (like moving from bare metal to RTOS, or supporting
networking).

> 
>> cost.  There is almost nothing to gain from a move to 64-bit, but the
>> cost would be a good deal higher.
> 
> Why is the cost "a good deal higher"?  Code/data footprints don't
> uniformly "double" in size.  The CPU doesn't slow down to handle
> bigger data.

Some parts of code and data /do/ double in size - but not uniformly, of
course.  But your chip is bigger, faster, requires more power, has wider
buses, needs more advanced memories, has more balls on the package,
requires finer pitched pcb layouts, etc.

In theory, you /could/ make a microcontroller in a 64-pin LQFP and
replace the 72 MHz Cortex-M4 with a 64-bit ARM core at the same clock
speed.  The die would only cost two or three times more, and take
perhaps less than 10 times the power for the core.  But it would be so
utterly pointless that no manufacturer would make such a device.

So a move to 64-bit in practice means moving from a small, cheap,
self-contained microcontroller to an embedded PC.  Lots of new
possibilities, lots of new costs of all kinds.

Oh, and the cpu /could/ be slower for some tasks - bigger cpus that are
optimised for throughput often have poorer latency and more jitter for
interrupts and other time-critical features.

> 
>>  So it is not going to happen - at
>> least not more than a very small and very gradual change.
> 
> We got 32b processors NOT because the embedded world cried out for
> them but, rather, because of the influence of the 32b desktop world.
> We've had 32b processors since the early 80's.  But, we've only had
> PCs since about the same timeframe!  One assumes ubiquity in the
> desktop world would need to happen before any real spillover to embedded.
> (When the "desktop" was an '11 sitting in a back room, it wasn't seen
> as ubiquitous.)

I don't assume there is any direct connection between the desktop world
and the embedded world - the needs are usually very different.  There is
a small overlap in the area of embedded devices with good networking and
a gui, where similarity to the desktop world is useful.

We have had 32-bit microcontrollers for decades.  I used a 16-bit
Windows system when working with my first 32-bit microcontroller.  But
at that time, 32-bit microcontrollers cost a lot more and required more
from the board (external memories, more power, etc.) than 8-bit or
16-bit devices.  That has gradually changed with an almost total
disregard for what has happened in the desktop world.

Yes, the embedded world /did/ cry out for 32-bit microcontrollers for an
increasing proportion of tasks.  We cried many tears when then
microcontroller manufacturers offered to give more flash space to their
8-bit devices by having different memory models, banking, far jumps, and
all the other shit that goes with not having a big enough address space.
 We cried out when we wanted to have Ethernet and the microcontroller
only had a few KB of ram.  I have used maybe 6 or 8 different 32-bit
microcontroller processor architectures, and I used them because I
needed them for the task.  It's only in the past 5+ years that I have
been using 32-bit microcontrollers for tasks that could be done fine
with 8-bit devices, but the 32-bit devices are smaller, cheaper and
easier to work with than the corresponding 8-bit parts.

> 
> In the future, we'll see the 64b *phone* world drive the evolution
> of embedded designs, similarly.  (do you really need 32b/64b to
> make a phone?  how much code is actually executing at any given
> time and in how many different containers?)
> 

We will see that on devices that are, roughly speaking, tablets -
embedded systems with a good gui, a touchscreen, networking.  And that's
fine.  But these are a tiny proportion of the embedded devices made.

> 
>> The OP sounds more like a salesman than someone who actually works with
>> embedded development in reality.
> 
> Possibly.  Or, just someone that wanted to stir up discussion...
> 

Could be.  And there's no harm in that!

David Brown <david.brown@hesbynett.no> wrote:
> But for microcontrollers - which dominate embedded systems - there has
> been a lot to gain by going from 8-bit and 16-bit to 32-bit for little
> cost.  There is almost nothing to gain from a move to 64-bit, but the
> cost would be a good deal higher.  So it is not going to happen - at
> least not more than a very small and very gradual change.

I think there will be divergence about what people mean by an N-bit system:

Register size
Unit of logical/arithmetical processing
Memory address/pointer size
Memory bus/cache width

I think we will increasingly see parts which have different sizes on one
area but not the other.

For example, for doing some kinds of logical operations (eg crypto), having
64-bit registers and ALU makes sense, but you might only need kilobytes of
memory so only have <32 address bits.

For something else, like a microcontroller that's hung off the side of a
bigger system (eg the MCU on a PCIe card) you might want the ability to
handle 64 bit addresses but don't need to pay the price for 64-bit
registers.

Or you might operate with 16 or 32 bit wide external RAM chip, but your
cache could extend that to a wider word width.

There are many permutations, and I think people will pay the cost where it
benefits them and not where it doesn't.  

This is not a new phenomenon, of course.  But for a time all these numbers
were in the range between 16 and 32 bits, which made 32 simplest all round. 
Just like we previously had various 8/16 hybrids (eg 8 bit datapath, 16 bit
address) I think we're going to see more 32/64 hybrids.

Theo

On Tuesday, June 8, 2021 at 2:39:29 AM UTC-5, Don Y wrote:
> On 6/7/2021 10:59 PM, David Brown wrote: 
> > 8-bit microcontrollers are still far more common than 32-bit devices in 
> > the embedded world (and 4-bit devices are not gone yet). At the other 
> > end, 64-bit devices have been used for a decade or two in some kinds of 
> > embedded systems.
> I contend that a good many "32b" implementations are really glorified 
> 8/16b applications that exhausted their memory space. I still see lots 
> of designs build on a small platform (8/16b) and augment it -- either 
> with some "memory enhancement" technology or additional "slave" 
> processors to split the binaries. Code increases in complexity but 
> there doesn't seem to be a need for the "work-per-unit-time" to. 
> 
> [This has actually been the case for a long time. The appeal of 
> newer CPUs is often in the set of peripherals that accompany the 
> processor, not the processor itself.]
> > We'll see 64-bit take a greater proportion of the embedded systems that 
> > demand high throughput or processing power (network devices, hard cores 
> > in expensive FPGAs, etc.) where the extra cost in dollars, power, 
> > complexity, board design are not a problem. They will probably become 
> > more common in embedded Linux systems as the core itself is not usually 
> > the biggest part of the cost. And such systems are definitely on the 
> > increase. 
> > 
> > But for microcontrollers - which dominate embedded systems - there has 
> > been a lot to gain by going from 8-bit and 16-bit to 32-bit for little
> I disagree. The "cost" (barrier) that I see clients facing is the 
> added complexity of a 32b platform and how it often implies (or even 
> *requires*) a more formal OS underpinning the application. Where you 
> could hack together something on bare metal in the 8/16b worlds, 
> moving to 32 often requires additional complexity in managing 
> mechanisms that aren't usually present in smaller CPUs (caches, 
> MMU/MPU, DMA, etc.) Developers (and their organizations) can't just 
> play "coder cowboy" and coerce the hardware to behaving as they 
> would like. Existing staff (hired with the "bare metal" mindset) 
> are often not equipped to move into a more structured environment. 
> 
> [I can hack together a device to meet some particular purpose 
> much easier on "development hardware" than I can on a "PC" -- simply 
> because there's too much I have to "work around" on a PC that isn't 
> present on development hardware.] 
> 
> Not every product needs a filesystem, network stack, protected 
> execution domains, etc. Those come with additional costs -- often 
> in the form of a lack of understanding as to what the ACTUAL 
> code in your product is doing at any given time. (this isn't the 
> case in the smaller MCU world; it's possible for a developer to 
> have written EVERY line of code in a smaller platform)
> > cost. There is almost nothing to gain from a move to 64-bit, but the 
> > cost would be a good deal higher.
> Why is the cost "a good deal higher"? Code/data footprints don't 
> uniformly "double" in size. The CPU doesn't slow down to handle 
> bigger data. 
> 
> The cost is driven by where the market goes. Note how many 68Ks found 
> design-ins vs. the T11, F11, 16032, etc. My first 32b design was 
> physically large, consumed a boatload of power and ran at only a modest 
> improvement (in terms of system clock) over 8b processors of its day. 
> Now, I can buy two orders of magnitude more horsepower PLUS a 
> bunch of built-in peripherals for two cups of coffee (at QTY 1)
> > So it is not going to happen - at 
> > least not more than a very small and very gradual change.
> We got 32b processors NOT because the embedded world cried out for 
> them but, rather, because of the influence of the 32b desktop world. 
> We've had 32b processors since the early 80's. But, we've only had 
> PCs since about the same timeframe! One assumes ubiquity in the 
> desktop world would need to happen before any real spillover to embedded. 
> (When the "desktop" was an '11 sitting in a back room, it wasn't seen 
> as ubiquitous.) 
> 
> In the future, we'll see the 64b *phone* world drive the evolution 
> of embedded designs, similarly. (do you really need 32b/64b to 
> make a phone? how much code is actually executing at any given 
> time and in how many different containers?) 
> 
> [The OP suggests MCus with radios -- maybe they'll be cell phone 
> radios and *not* wifi/BLE as I assume he's thinking! Why add the 
> need for some sort of access point to a product's deployment if 
> the product *itself* can make a direct connection??] 
> 
> My current design can't fill a 32b address space (but, that's because 
> I've decomposed apps to the point that they can be relatively small). 
> OTOH, designing a system with a 32b limitation seems like an invitation 
> to do it over when 64b is "cost effective". The extra "baggage" has 
> proven to be relatively insignificant (I have ports of my codebase 
> to SPARC as well as Atom running alongside a 32b ARM)
> > The OP sounds more like a salesman than someone who actually works with 
> > embedded development in reality.
> Possibly. Or, just someone that wanted to stir up discussion...

|> I contend that a good many "32b" implementations are really glorified
|> 8/16b applications that exhausted their memory space.

The only thing that will take more than 4GB is video or a day's worth of photos.
So there is likely to be some embedded aps that need a > 32-bit address space.
Cost, size or storage capacity are no longer limiting factors.

Am trying to puzzle out what a 64-bit embedded processor should look like.
At the low end, yeah, a simple RISC processor.  And support for complex arithmetic
using 32-bit floats?  And support for pixel alpha blending using quad 16-bit numbers?
32-bit pointers into the software?

On 08/06/2021 21:38, James Brakefield wrote:

Could you explain your background here, and what you are trying to get
at?  That would make it easier to give you better answers.

> The only thing that will take more than 4GB is video or a day's worth of photos.

No, video is not the only thing that takes 4GB or more.  But it is,
perhaps, one of the more common cases.  Most embedded systems don't need
anything remotely like that much memory - to the nearest percent, 100%
of embedded devices don't even need close to 4MB of memory (ram and
flash put together).

> So there is likely to be some embedded aps that need a > 32-bit address space.

Some, yes.  Many, no.

> Cost, size or storage capacity are no longer limiting factors.

Cost and size (and power) are /always/ limiting factors in embedded systems.

> 
> Am trying to puzzle out what a 64-bit embedded processor should look like.

There are plenty to look at.  There are ARMs, PowerPC, MIPS, RISC-V.
And of course there are some x86 processors used in embedded systems.

> At the low end, yeah, a simple RISC processor.

Pretty much all processors except x86 and brain-dead old-fashioned 8-bit
CISC devices are RISC.  Not all are simple.

>  And support for complex arithmetic
> using 32-bit floats?

A 64-bit processor will certainly support 64-bit doubles as well as
32-bit floats.  Complex arithmetic is rarely needed, except perhaps for
FFT's, but is easily done using real arithmetic.  You can happily do
32-bit complex arithmetic on an 8-bit AVR, albeit taking significant
code space and run time.  I believe the latest gcc for the AVR will do
64-bit doubles as well - using exactly the same C code you would on any
other processor.

>  And support for pixel alpha blending using quad 16-bit numbers?

You would use a hardware 2D graphics accelerator for that, not the
processor.

> 32-bit pointers into the software?
> 

With 64-bit processors you usually use 64-bit pointers.

On 08/06/2021 16:46, Theo wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> But for microcontrollers - which dominate embedded systems - there has
>> been a lot to gain by going from 8-bit and 16-bit to 32-bit for little
>> cost.  There is almost nothing to gain from a move to 64-bit, but the
>> cost would be a good deal higher.  So it is not going to happen - at
>> least not more than a very small and very gradual change.
> 
> I think there will be divergence about what people mean by an N-bit system:

There has always been different ways to measure the width of a cpu, and
different people have different preferences.

> 
> Register size

Yes, that is common.

> Unit of logical/arithmetical processing

As is that.  Sometimes the width supported by general instructions
differs from the ALU width, however, resulting in classifications like
8/16-bit for the Z80 and 16/32-bit for the 68000.

> Memory address/pointer size

Yes, also common.

> Memory bus/cache width

No, that is not a common way to measure cpu "width", for many reasons.
A chip is likely to have many buses outside the cpu core itself (and the
cache(s) may or may not be considered part of the core).  It's common to
have 64-bit wide buses on 32-bit processors, it's also common to have
16-bit external databuses on a microcontroller.  And the cache might be
128 bits wide.

> 
> I think we will increasingly see parts which have different sizes on one
> area but not the other.
> 

That has always been the case.

> For example, for doing some kinds of logical operations (eg crypto), having
> 64-bit registers and ALU makes sense, but you might only need kilobytes of
> memory so only have <32 address bits.

You need quite a few KB of ram for more serious cryptography.  But it
sounds more like you are talking about SIMD or vector operations here,
which are not considered part of the "normal" width of the cpu.  Modern
x86 cpus might have 512 bit SIMD registers - but they are still 64-bit
processors.

But you are right that you might want some parts of the system to be
wider and other parts thinner.

> 
> For something else, like a microcontroller that's hung off the side of a
> bigger system (eg the MCU on a PCIe card) you might want the ability to
> handle 64 bit addresses but don't need to pay the price for 64-bit
> registers.
> 
> Or you might operate with 16 or 32 bit wide external RAM chip, but your
> cache could extend that to a wider word width.
> 
> There are many permutations, and I think people will pay the cost where it
> benefits them and not where it doesn't.  
> 

Agreed.

> This is not a new phenomenon, of course.  But for a time all these numbers
> were in the range between 16 and 32 bits, which made 32 simplest all round. 
> Just like we previously had various 8/16 hybrids (eg 8 bit datapath, 16 bit
> address) I think we're going to see more 32/64 hybrids.
> 

32-bit processors have often had 64-bit registers for floating point,
and 64-bit operations of various sorts.  It is not new.