Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30668 > unrolled thread

64-bit embedded computing is here and now

Back to article view | Back to comp.arch.embedded

Contents

  64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-07 07:47 -0700
    Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-07 14:13 -0700
    Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-07 22:31 -0700
      Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 07:59 +0200
        Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 00:39 -0700
          Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 13:04 +0200
            Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 17:30 -0700
              Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 09:17 +0200
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 03:12 -0700
                  Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-12 12:58 -0400
                    Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-12 12:40 -0700
                Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 09:41 -0700
                  Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 10:12 -0700
                  Re: 64-bit embedded computing is here and now DJ Delorie <dj@delorie.com> - 2021-06-09 13:16 -0400
                  Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 13:44 -0400
                    Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:03 +0300
                      Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 15:22 -0400
                        Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 12:58 -0700
                          Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:26 -0700
                        Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 23:12 +0300
          Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 12:38 -0700
            Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:11 +0200
              Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 14:25 -0700
              Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-09 00:16 -0400
                Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:40 +0200
                  Re: 64-bit embedded computing is here and now Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-06-09 22:52 +0200
                    Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-10 09:37 +0200
            Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 01:01 +0300
              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:29 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 20:56 +0300
                  Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 17:12 -0700
                    Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 13:45 +0300
                      Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 06:55 -0700
                        Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 18:32 +0300
                          Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 14:09 -0700
                            Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 01:13 +0300
                              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 21:55 -0700
                                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 14:14 +0300
                                  Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 05:10 -0700
                                    Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 16:35 +0300
                                      Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 16:24 -0700
                Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-14 05:41 -0400
            Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:51 -0700
            Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-08 18:20 -0700
              Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 18:07 +0100
                Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 10:34 -0700
                  Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:37 -0700
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:43 -0700
        Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-08 15:46 +0100
          Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:18 +0200
            Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-08 23:39 +0300
              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:33 -0700
              Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:59 +0200
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 21:00 +0300
                  Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 20:55 +0200
                    Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:06 +0300
          Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:00 -0700
            Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 13:10 +0100
              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 06:19 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#30723

On 6/11/2021 6:35 AM, Dimiter_Popoff wrote:
> On 6/11/2021 15:10, Don Y wrote:
>> On 6/11/2021 4:14 AM, Dimiter_Popoff wrote:
>>> On 6/11/2021 7:55, Don Y wrote:
>>>> ...
>>>> As I tease more of your design out of you, it becomes apparent why
>>>> you "need" a flat address space.  You push much of the responsibility
>>>> for managing the environment into the developer's hands.  *He* decides
>>>> which regions of memory to share.  He talks to the MMU (even if through
>>>> an API).  He directly retrieves values from other tasks.  Etc.
>>>
>>> It is not true that the developer is in control of all that. Messaging
>>> from one task to another goes through a system call.
>>
>> But the client directly retrieves the values.  The OS doesn't provide
>> them (at least, that's what you said previously)
> 
> I am not sure what this means. The recipient task has advertised a field
> where messages can be queued, the sending task makes a system call
> designating the message and which task is to receive it; during that
> call execution the message is written into the memory of the recipient.
> Then at some point later the recipient can see that and process the
> message. What more do you need?
> 
>>
>>> Anyway, I am not interested in discussing dps here/now.
>>>
>>> The *only* thing I would like you to answer me is why you think
>>> a linear 64 bit address space can add vulnerability to a design.
>>
>> Please tell me where I said it -- in and of itself -- makes a
>> design vulnerable?
> 
> This is how the exchange started:
> 
> 
>>>>> Dimiter_Popoff wrote:
>>>>>
>>>>>
>>>>> The real value in 64 bit integer registers and 64 bit address space is
>>>>> just that, having an orthogonal "endless" space (well I remember some
>>>>> 30 years ago 32 bits seemed sort of "endless" to me...).
>>>>>
>>>>> Not needing to assign overlapping logical addresses to anything
>>>>> can make a big difference to how the OS is done.
>>>>
>>>> That depends on what you expect from the OS. If you are
>>>> comfortable with the possibility of bugs propagating between
>>>> different subsystems, then you can live with a logical address
>>>> space that exactly coincides with a physical address space.
>>>
>>> So how does the linear 64 bt address space get in the way of
>>> any protection you want to implement? Pages are still 4 k and
>>> each has its own protection attributes governed by the OS,
>>> it is like that with 32 bit processors as well (I talk power, I am
>>> not interested in half baked stuff like ARM, risc-v etc., I don't
>>> know if there could be a problem like that with one of these).
>>
>> With a linear address space, you typically have to link EVERYTHING
>> as a single image to place each thing in its own piece of memory
>> (or use segment based addressing).
> 
> Now if you have missed the "logical" word in my post I can
> understand why you went into all that. But I was quite explicit
> about it.

It's easier to get some part of a flat address space *wrong*.
And, as you've exposed (even if hiding behind an MMU) everything,
that presents an opportunity for SOMETHING to leak -- that
shouldn't.

Alpha (OS) took this to an extreme.  Each object had its own
address space fitted neatly onto some number of (contiguous?)
pages.

When you invoked a method on an object, you trapped to the OS.
The OS marshalled your arguments into an "input page(s)"
and created an empty "ouput page(s)".  It then built an address
space consisting of the input and output pages (at logical
addresses that an object recognized, by convention) AND the
page(s) for the object's code.  NOTHING ELSE.  Then, transfered
control to one of N entry points in the first page of the
object's implementation (another convention).

So, the object's code had free access to its inputs, its
own code and it's outputs.  Attempting to reference anything else
would signal a protection violation.  There *is* nothing else!
A bug, errant pointer, exploit, etc. would just land on
unmapped memory!

[Note that an object could invoke ANOTHER object -- but, that
object would then be built up in yet another address space
while the current object's address space was idled]

This approach makes it hard for "active" objects to be
made persistent (e.g., a *process* that is "doing something
yet has an object interface) so objects tend to want to be
passive.

I don't go to these extremes.  But close!

An instance of a "foo" object is served by (an instance of)
a foo_object_server.  That server can serve multiple foo objects
concurrently (and can even use multiple threads to do so).

The object_server accepts the messages for the object and
invokes the corresponding method in the context of that
particular object.  Because it exists in an isolated address
space, no other objects/clients can examine the object's
implementation -- the code executed by the object_server
to handle each request/method as well as the "private data"
associated with an object instance.  Nor can they interfere
with any of this.

Another instance of a foo_object_server can serve other
foo objects -- on the same node or on some other node.

[i.e., to migrate a foo object to another node, instantiate
a foo_object_server on the target node -- if one doesn't
already exist there -- and then transfer the internal
representation of the desired foo object to that other
server.  And, arrange for all "Interfaces" to that
particular object to simultaneously be transferred
(so future connections to the object are unaware of
the migration)]

As my *_object_servers can be persistent, an object can be
active -- can continue doing something even after (or before!)
every request (method invocation) has been serviced.  It's
up to the object designer to decide the semantics of
each method.

E.g., should garagedoor.open() start the opening process and
wait until it is complete before returning to the caller?
Or, should it just start the process and return immediately?
Should rosebush.irrigate() block the caller for the hour or two
it takes to irrigate?

> Anyway, I am glad we agree that a 64 bit logical address space
> is no obstacle to security. From there on it can only be something
> to make programming life easier.

It's not an obstacle.  But, it's an *opportunity* for a bug to
manifest or information to leak or an exploit to gain a beachhead.
The less stuff that can be exposed (even accidentally), the less
opportunity for these problems to manifest.

Think of all the "account compromises" that have occurred.
All of the "personal/account information" that has leaked.
Why was that information accessible?  I'm sure it wasn't
SUPPOSED to be accessible.  But, why was it even resident
ANYWHERE on an out-facing machine?

If I make a purchase, I provide a CC number, name ("as it
appears on the card") and the CVC number off the back.
To validate my card, it would be foolish to:
     select name, cvc from credit_cards where card_number = CC_provided
     if name != name_provided
     or cvc  != cvc_provided
     then reject_transaction
while this, by itself, is correct and "secure", the approach
requires the credit_cards table to contain ALL of the data for
every credit card.  AND, has the potential to allow an
adversary to trick the software into revealing all or part of it!

If, OTOH, the implementation was:
     if !verify(CC_provided, name_provided, cvc_provided)
     then reject_transaction
all of the details can be hidden behind verify() which can
execute on a more secure processor with a more secure protocol.
E.g., compute a hash of these three values and ask the
DBMS if the hash is correct, without ever having the raw data
stored!

An adversary could try to *guess* a valid combination of
name/cc/cvc --- but, would have to repeatedly issue "validate()"
requests -- which can then attract suspicion.

[This is why I allow an object to sever an incoming connection
if *it* detects behaviours that it considers harmful or
suspicious; the OS has no way of making that determination!]

Making MORE things inaccessible (i.e., everything that doesn't
NEED to be accessible -- like Alpha's approach) improves
reliability and security.  Because REAL implementations
always have oversights and bugs -- things that you hadn't
considered or for which you hadn't tested.

Again, your application and application domain is likely far
more benign than mine.  The people operating your devices
are likely more technically capable (which MIGHT lead to
better process compliance).  How likely would one of your
instruments find itself targeted by an attacker?  And, your
budget is likely tighter than mine (in terms of money,
resources and performance).

I can *afford* a more featureful OS to offload more of the
work/vulnerability from developers.  Doing so lets more
developers tinker in my environment.  And, makes the
resulting design (which evolves as each developer adds
to the system) more robust from attack, fault, compromise.

[An adversary is more likely to target one of my systems
than yours:  "Deposit $1,000 in this bitcoin account to
regain control over your home/factory/business..."]

[toc] | [prev] | [next] | [standalone]

#30726

On Tue, 8 Jun 2021 18:29:24 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 6/8/2021 3:01 PM, Dimiter_Popoff wrote:
>
>>> 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?
>> 
>> The real value in 64 bit integer registers and 64 bit address space is
>> just that, having an orthogonal "endless" space (well I remember some
>> 30 years ago 32 bits seemed sort of "endless" to me...).
>> 
>> Not needing to assign overlapping logical addresses to anything
>> can make a big difference to how the OS is done.
>
>That depends on what you expect from the OS.  If you are
>comfortable with the possibility of bugs propagating between
>different subsystems, then you can live with a logical address
>space that exactly coincides with a physical address space.

Propagation of bugs is mostly independent of the logical address
space.  In actual fact, existing SAS operating systems are MORE
resistant to problems than MPAS systems.


>But, consider how life was before Windows used compartmentalized
>applications (and OS).  How easily it is for one "application"
>(or subsystem) to cause a reboot -- unceremoniously.

You can kill a Windows systems with 2 lines of code:
  :
SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_TIME_CRITICAL);
while( 1 );
  :


>The general direction (in software development, and, by
>association, hardware) seems to be to move away from unrestrained
>access to the underlying hardware in an attempt to limit the
>amount of damage that a "misbehaving" application can cause.
>
>You see this in languages designed to eliminate dereferencing
>pointers, pointer arithmetic, etc.  Languages that claim to
>ensure your code can't misbehave because it can only do
>exactly what the language allows  (no more injecting ASM
>into your HLL code).

Managed runtimes.

Pointers, per se, are not a problem.  However, explicit pointer
arithmetic /is/ known to be the cause of many program bugs.  

IMO high level languages should not allow it - there's nothing you can
do with (source level) pointer arithmetic can do that can't be done
more safely using array indexing.  The vast majority of programmers
should just let the compiler deal with it.


>> 32 bit FPU seems useless to me, 64 bit is OK. Although 32 FP
>> *numbers* can be quite useful for storing/passing data.
>
>32 bit numbers have appeal if you're registers are 32b;
>they "fit nicely".  Ditto 64b in 64b registers.

Depends on the problem domain.  If you don't need the extra precision,
calculations with 32b floats often are twice or more as fast as with
64b doubles.

Particularly with SIMD, you gain both  by 32b calculations taking
fewer cycles than 64b, and by being able to perform twice as many
simultaneous calculations.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#30682

On 6/8/2021 12:38 PM, James Brakefield wrote:

> |> 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.

That's not true.  For example, I rely on a "PC" in my current design
to support the RDBMS.  Otherwise, I would have to design a "special
node" (I have a distributed system) that had the resources necessary
to process multiple concurrent queries in a timely fashion; I can
put 100GB of RAM in a PC (whereas my current nodes only have 256MB).

The alternative is to rely on secondary (disk) storage -- which is
even worse!

And "video" is incredibly nondescript.  It conjures ideas of STBs.
Instead, I see a wider range of applications in terms of *vision*.

E.g., let your doorbell camera "notice motion", recognize that
motion as indicative of someone/thing approaching it (e.g.,
a visitor), recognize the face/features of the visitor and
alert you to its presence (if desired).  No need to involve a
cloud service to do this.

[My "doorbell" is a camera/microphone/speaker.  *If* I want to
know that you are present, *it* will tell me.  Or, if told to
do so, will grant you access to the house (even in my absence).
For "undesirables", I'm mounting a coin mechanism adjacent to
the entryway (our front door is protected by a gated porch area):
"Deposit 25c to ring bell.  If we want to talk to you, your
deposit will be refunded.  If *not*, consider that the *cost* of
pestering us!"]

There are surveillance cameras discretely placed around the exterior
of the house (don't want the place to look like a frigging *bank*!).
One of them has a clear view of the mailbox (our mail is delivered
via lettercarriers riding in mail trucks).  Same front door camera
hardware.  But, now:  detect motion; detect motion STOPPING
proximate to mailbox (for a few seconds or more); detect motion
resuming; signal "mail available".  Again, no need to involve a
cloud service to accomplish this.  And, when not watching for mail
delivery, it's performing "general" surveillance -- mail detection
is a "free bonus"!

Imagine designing a vision-based inspection system where you "train"
the CAMERA -- instead of some box that the camera connects to.  And,
the CAMERA signals accept/reject directly.

[I use a boatload of cameras, here; they are cheap sensors -- the
"cost" lies in the signal processing!]

> 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.

No, cost size and storage are ALWAYS limiting factors!

E.g., each of my nodes derive power from the wired network connection.
That puts a practical limit of ~12W on what a node can dissipate.
That has to support the processing core plus any local I/Os!  Note
that dissipated power == heat.  So, one also has to be conscious of
how that heat will affect the devices' environs.

(Yes, there are schemes to increase this to ~100W but now the cost
of providing power -- and BACKUP power -- to a remote device starts
to be a sizeable portion of the product's cost and complexity).

My devices are intended to be "invisible" to the user -- so, they
have to hide *inside* something (most commonly, the walls or
ceiling -- in standard Jboxes for accessibility and Code compliance).
So, that limits their size/volume (mine are about the volume of a
standard duplex receptacle -- 3 cu in -- so fit in even the smallest
of 1G boxes... even pancake boxes!)

They have to be inexpensive so I can justify using LOTS of them
(I will have 240 deployed, here; my industrial beta site will have
over 1000; commercial beta site almost a similar number).  Not only
is the cost of initial acquisition of concern, but also the *perceived*
cost of maintaining the hardware in a functional state (customer
doesn't want to have $10K of spares on hand for rapid incident response
and staff to be able to diagnose and repair/replace "on demand")

In my case, I sidestep the PERSISTENT storage issue by relegating that
to the RDBMS.  In *that* domain, I can freely add spinning rust or
an SSD without complicating the design of the rest of the nodes.
So, "storage" becomes:
- how much do I need for a secure bootstrap
- how much do I need to contain a downloaded (from the RDBMS!) binary
- how much do I need to keep "local runtime resources"
- how much can I exploit surplus capacity *elsewhere* in the system
   to address transient needs

Imagine what it would be like having to replace "worn" SD cards
at some frequency in hundreds of devices scattered around hundreds
of "invisible" places!  Almost as bad as replacing *batteries* in
those devices!

[Have you ever had an SD card suddenly write protect itself?]

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

"Should"?  That depends on what you expect it to do for you.
The nonrecurring cost of development will become an ever-increasing
portion of the device's "cost".  If you sell 10K units but spend
500K on development (over its lifetime), you've justification for
spending a few more dollars on recurring costs *if* you can realize
a reduction in development/maintenance costs (because the development
is easier, bugs are fewer/easier to find, etc.)

Developers (and silicon vendors, as Good Business Practice)
will look at their code and see what's "hard" to do, efficiently.
Then, consider mechanisms that could make that easier or
more effective.

I see the addition of hardware features that enhance the robustness
of the software development *process*.  E.g., allowing for compartmentalizing
applications and subsystems more effectively and *efficiently*.

[I put individual objects into their own address space containers
to ensure Object A can't be mangled by Client B (or Object C).  As
a result, talking to an object is expensive because I have to hop
back and forth across that protection boundary.  It's even worse
when the targeted object is located on some other physical node
(as now I have the transport cost to contend with).]

Similarly, making communications more robust.  We already see that
with crypto accelerators.  The idea of device "islands" is
obsolescent.  Increasingly, devices will interact with other
devices to solve problems.  More processing will move to the
edge simply because of scaling issues (I can add more CPUs
far more effectively than I can increase the performance of
a "centralized" CPU; add another sense/control point?  let *it*
bring some processing abilities along with it!).

And, securing the product from tampering/counterfeiting; it seems
like most approaches, to date, have some hidden weakness.  It's hard
to believe hardware can't ameliorate that.  The fact that "obscurity"
is still relied upon by silicon vendors suggests an acknowledgement
of their weaknesses.

Beyond that?  Likely more DSP-related support in the "native"
instruction set (so you can blend operations between conventional
computing needs and signal processing related issues).

And, graphics acceleration as many applications implement user
interfaces in the appliance.

There may be some other optimizations that help with hashing
or managing large "datasets" (without them being considered
formal datasets).

Power management (and measurement) will become increasingly
important (I spend almost as much on the "power supply"
as I do on the compute engine).  Developers will want to be
able to easily ascertain what they are consuming as well
as why -- so they can (dynamically) alter their strategies.
In addition to varying CPU clock frequency, there may be
mechanisms to automatically (!) power down sections of
the die based on observed instruction sequences (instead
of me having to explicitly do so).

[E.g., I shed load when I'm running off backup power.
This involves powering down nodes as well as the "fields"
on selective nodes.  How do I decide *which* load to shed to
gain the greatest benefit?]

Memory management (in the conventional sense) will likely
see more innovation.  Instead of just "settling" for a couple
of page sizes, we might see "adjustable" page sizes.
Or, the ability to specify some PORTION of a *particular*
page as being "valid" -- instead of treating the entire
page as such.

Scheduling algorithms will hopefully get additional
hardware support.  E.g., everything is deadline driven
in my design ("real-time").  So, schedulers are concerned
with evaluating the deadlines of "ready" tasks -- which
can vary, over time, as well as may need further qualification
based on other criteria (e.g., least-slack-time scheduling)

Everything in my system is an *opaque* object on which a
set of POSSIBLE methods that can be invoked.  But, each *Client*
of that object (an Actor may be multiple Clients if it possesses
multiple different Handles to the Object) is constrained as to
which methods can be invoked via a particular Handle.

So, I can (e.g.) create an Authenticator object that has methods like
"set_passphrase" and "test_passphrase" and "invalidate_passphrase".
Yet, no "disclose_passphrase" method (for obvious reasons).
I can create an Interface to one privileged Client that
allows it to *set* a new passphrase.  And, all other Interfaces
(to that Client as well as others!) may all be restricted to
only *testing* the passphrase ("Is it 'foobar'?").  And, I can
limit the number of attempts that you can invoke a particular
method over a particular interface so the OS does the enforcement
instead of relying on the Server to do so.

[What's to stop a Client from hammering on the Server (Authenticator
Object) repeatedly -- invoking test_passphrase with full knowledge
that it doesn't know the correct passhrase:  "Is it 'foobar'?"
"Is it 'foobar'?" "Is it 'foobar'?" "Is it 'foobar'?" "Is it 'foobar'?"
The Client has been enabled to do this; that doesn't mean he can't or
won't abuse it!

Note that unlimited access means the server has to respond to each of
those method invocations.  By contrast, putting a limit on them
means the OS can block the invocation from ever reaching the Object
(and needlessly tying up the Object's resources).  A capabilities
based system that relies on encrypted tokens means the Server has
to decrypt a token in order to determine that it is invalid;
the Server's resources are consumed instead of the Client's]

It takes effort (in the kernel) to verify that a Client *can* access a
particular Object (i.e., has a Handle to it) AND that the Client can
invoke THAT particular Method on that Object via this Handle (bound to
a particular Object *Interface*) as well as verifying the format of
the data, converting to a format suitable for the targeted Object
(which may use a different representational structure) for a
particular Version of the Interface...

I can either skimp on performing some of these checks (and rely
on other mechanisms to ensure the security and reliability of
the codebase -- in the presence of unvetted Actors) or hope
that some hardware mechanism in the processor makes these a bit
easier.

> 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?

I doubt complex arithmetic will have much play.  There might be support for
*building* larger data types (e.g., I use BigRationals which are incredibly
inefficient).  But, the bigger bang will be for operators that allow
tedious/iterative solutions to be implemented in constant time.  This,
for example, is why a hardware multiply (or other FPU capabilities)
is such a win -- consider the amount of code that is replaced by a single
op-code!  Ditto things like "find first set bit", etc.

Why stick with 32b floats when you can likely implement doubles with a bit
more microcode (surely faster than trying to do wider operations built from
narrower ones)?

There's an entirely different mindset when you start thinking in
terms of "bigger processors".  I.e., the folks who see 32b processors as
just *wider* 8/16b processors have typically not made this adjustment.
It's like trying to "sample the carry" in a HLL (common in ASM)
instead of concentrating on what you REALLY want to do and letting
the language make it easier for you to express that.

Expect to see people making leaps forward in terms of what they
expect from the solutions they put forth.  Anything that you could
do with a PC, before, can now be done *in* a handheld flashlight!

[toc] | [prev] | [next] | [standalone]

#30684

James Brakefield <jim.brakefield@ieee.org> writes:
> Am trying to puzzle out what a 64-bit embedded processor should look like.

Buy yourself a Raspberry Pi 4 and set it up to run your fish tank via a
remote web browser.  There's your 64 bit embedded system.

[toc] | [prev] | [next] | [standalone]

#30695

Paul Rubin <no.email@nospam.invalid> wrote:
> James Brakefield <jim.brakefield@ieee.org> writes:
> > Am trying to puzzle out what a 64-bit embedded processor should look like.
> 
> Buy yourself a Raspberry Pi 4 and set it up to run your fish tank via a
> remote web browser.  There's your 64 bit embedded system.

I suppose there's a question of what embedded tasks intrinsically require
>4GiB RAM, and those that do so because it makes programmers' lives easier?

In other words, you /can/ write a function to detect if your fish tank is
hot or cold in Javascript that runs in a web app on top of Chromium on top
of Linux.  Or you could make it out of a 6502, or a pair of logic gates.

That's complexity that's not fundamental to the application.  OTOH
maintaining a database that's larger than 4GB physically won't work without
that amount of memory (or storage, etc).

There are obviously plenty of computer systems doing that, but the question
I don't know is what applications can be said to be 'embedded' but need that
kind of RAM.

Theo

[toc] | [prev] | [next] | [standalone]

#30698

Theo <theom+news@chiark.greenend.org.uk> writes:
>> Buy yourself a Raspberry Pi 4 and set it up to run your fish tank via a
>> remote web browser.  There's your 64 bit embedded system.
> I suppose there's a question of what embedded tasks intrinsically require
>>4GiB RAM, and those that do so because it makes programmers' lives easier?

You can buy a Raspberry Pi 4 with up to 8gb of ram, but the most common
configuration is 2gb.  The cpu is 64 bit anyway because why not?

> There are obviously plenty of computer systems doing that, but the
> question I don't know is what applications can be said to be
> 'embedded' but need that kind of RAM.

Lots of stuff is using 32 bit cpus with a few KB of ram these days.  32
bits is displacing 8 bits in the MCU world.

Is 64 bit displacing 32 bit in application processors like the Raspberry
Pi, even when less than 4GB of ram is involved?  I think yes, at least
to some extent, and it will continue.  My fairly low end mobile phone
has 2GB of ram and a 64 bit 4-core processor, I think.

Will 64 bit MCU's displace 32 bit MCUs?  I don't know, maybe not.

Are application processors displacing MCU's in embedded systems?  Not
much in portable and wearable stuff (other than phones) at least for
now, but in larger devices I think yes, at least somewhat for now, and
probably more going forward.  Even if you're not using networking, it
makes software and UI development a heck of a lot easier.

[toc] | [prev] | [next] | [standalone]

#30710

On 6/9/2021 10:34 AM, Paul Rubin wrote:
> Theo <theom+news@chiark.greenend.org.uk> writes:
>>> Buy yourself a Raspberry Pi 4 and set it up to run your fish tank via a
>>> remote web browser.  There's your 64 bit embedded system.
>> I suppose there's a question of what embedded tasks intrinsically require
>>> 4GiB RAM, and those that do so because it makes programmers' lives easier?
> 
> You can buy a Raspberry Pi 4 with up to 8gb of ram, but the most common
> configuration is 2gb.  The cpu is 64 bit anyway because why not?

Exactly.  Are they going to give you a *discount* for a 32b version?

(Here, you can have this one for half of 'FREE'...)

>> There are obviously plenty of computer systems doing that, but the
>> question I don't know is what applications can be said to be
>> 'embedded' but need that kind of RAM.
> 
> Lots of stuff is using 32 bit cpus with a few KB of ram these days.  32
> bits is displacing 8 bits in the MCU world.
> 
> Is 64 bit displacing 32 bit in application processors like the Raspberry
> Pi, even when less than 4GB of ram is involved?  I think yes, at least
> to some extent, and it will continue.  My fairly low end mobile phone
> has 2GB of ram and a 64 bit 4-core processor, I think.
> 
> Will 64 bit MCU's displace 32 bit MCUs?  I don't know, maybe not.

Some due to need but, I suspect, most due to pricing or other
features not available in the 32b world.  Just like you don't
find PMMUs on 8/16b devices nor in-built NICs.

> Are application processors displacing MCU's in embedded systems?  Not
> much in portable and wearable stuff (other than phones) at least for
> now, but in larger devices I think yes, at least somewhat for now, and
> probably more going forward.  Even if you're not using networking, it
> makes software and UI development a heck of a lot easier.

This -------------------------------^^^^^^^^^^^^^^^^^^^^^^

Elbow room always takes some of the stress out of design.  You
don't worry (as much) about bumping into limits and, instead,
concentrate on solving the problem at hand.  The idea of
packing 8 'bools' into a byte (cuz I only had a hundred or
so of them available) is SO behind me, now!  Just use something
"more convenient"... eight of them!

I pass pages between processes as an efficiency hack -- even if
I'm only using a fraction of the page.  In smaller processors,
I'd be "upset" by this blatant "waste".  Instead, I shrug it off
and note that it gives me a uniform way of moving data around
(instead of having to tweek interfaces to LIMIT the amount
of data that I move; or "massage" the data JUST for transport).

My "calculator service" uses BigRationals -- because its easier than
trying to explain to users writing scripts that arithmetic can overflow,
suffer rounding errors, that order of operations is important, etc.

[toc] | [prev] | [next] | [standalone]

#30711

On 6/9/2021 10:07 AM, Theo wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
>> James Brakefield <jim.brakefield@ieee.org> writes:
>>> Am trying to puzzle out what a 64-bit embedded processor should look like.
>>
>> Buy yourself a Raspberry Pi 4 and set it up to run your fish tank via a
>> remote web browser.  There's your 64 bit embedded system.
> 
> I suppose there's a question of what embedded tasks intrinsically require
>> 4GiB RAM, and those that do so because it makes programmers' lives easier?
> 
> In other words, you /can/ write a function to detect if your fish tank is
> hot or cold in Javascript that runs in a web app on top of Chromium on top
> of Linux.  Or you could make it out of a 6502, or a pair of logic gates.
> 
> That's complexity that's not fundamental to the application.  OTOH
> maintaining a database that's larger than 4GB physically won't work without
> that amount of memory (or storage, etc).
> 
> There are obviously plenty of computer systems doing that, but the question
> I don't know is what applications can be said to be 'embedded' but need that
> kind of RAM.

Transcoding multiple video sources (for concurrent clients) in a single
appliance?

I have ~30 cameras, here.  Had I naively designed with them all connected
to a "camera processor", I suspect memory would be the least of my
concerns (motion and scene recognition in 30 places simultaneously?)
Instead, it was "easier" to give each camera its own processor.  And,
gain extended "remotability" as part of the process.

Remember, the 32b address space has to simultaneously hold EVERYTHING that
will need to be accessible to your application -- the OS, it's memory
requirements, the application(s) tasks, the stacks/heaps for the threads
they contain, the data to be processed (in and out), the memory-mapped
I/Os consumed by the SoC itself, etc.

When you HAVE a capability/resource, it somehow ALWAYS gets used!  ;-)

[toc] | [prev] | [next] | [standalone]

#30674

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

[toc] | [prev] | [next] | [standalone]

#30677

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.

[toc] | [prev] | [next] | [standalone]

#30678

On 6/8/2021 23:18, David Brown wrote:
> On 08/06/2021 16:46, Theo wrote:
>> ......
> 
>> 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 agree with your points and those of Theo, but the cache is basically
as wide as the registers? Logically, that is; a cacheline is several
times that, probably you refer to that.
Not that it makes much of a difference to the fact that 64 bit data
buses/registers in an MCU (apart from FPU registers, 32 bit FPUs are
useless to me) are unlikely to attract much interest, nothing of
significance to be gained as you said.
To me 64 bit CPUs are of interest of course and thankfully there are
some available, but this goes somewhat past what we call  "embedded".
Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
there is some real mess with their out of order execution, one needs to
do... hmmmm.. "sync", whatever they call it, all the time and there is
a huge performance cost because of that. Anybody heard anything about
it? (I only know what I was told).

Dimiter

[toc] | [prev] | [next] | [standalone]

#30686

On 6/8/2021 1:39 PM, Dimiter_Popoff wrote:

> Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
> there is some real mess with their out of order execution, one needs to
> do... hmmmm.. "sync", whatever they call it, all the time and there is
> a huge performance cost because of that. Anybody heard anything about
> it? (I only know what I was told).

Many processors support instruction reordering (and many compilers
will reorder the code they generate).  In each case, the reordering
is supposed to preserve semantics.

If the code "just runs" (and is never interrupted nor synchronized
with something else), the result should be the same.

If you want to be able to arbitrarily interrupt an instruction
sequence, then you need to take special measures.  This is why
we have barriers, the ability to flush caches, etc.

For "generic" code, the developer isn't involved with any of this.
Inside the kernel (or device drivers), its often a different
story...

[toc] | [prev] | [next] | [standalone]

#30690

On 08/06/2021 22:39, Dimiter_Popoff wrote:
> On 6/8/2021 23:18, David Brown wrote:
>> On 08/06/2021 16:46, Theo wrote:
>>> ......
>>
>>> 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 agree with your points and those of Theo, but the cache is basically
> as wide as the registers? Logically, that is; a cacheline is several
> times that, probably you refer to that.
> Not that it makes much of a difference to the fact that 64 bit data
> buses/registers in an MCU (apart from FPU registers, 32 bit FPUs are
> useless to me) are unlikely to attract much interest, nothing of
> significance to be gained as you said.
> To me 64 bit CPUs are of interest of course and thankfully there are
> some available, but this goes somewhat past what we call  "embedded".
> Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
> there is some real mess with their out of order execution, one needs to
> do... hmmmm.. "sync", whatever they call it, all the time and there is
> a huge performance cost because of that. Anybody heard anything about
> it? (I only know what I was told).
> 

sync instructions of various types can be needed to handle
thread/process synchronisation, atomic accesses, and coordination
between software and hardware registers.  Software normally runs with
the idea that it is the only thing running, and the cpu can re-order and
re-arrange the instructions and execution as long as it maintains the
illusion that the assembly instructions in the current thread are
executed one after the other.  These re-arrangements and parallel
execution can give very large performance benefits.

But it also means that when you need to coordinate with other things,
you need syncs, perhaps cache flushes, etc.  Full syncs can take
hundreds of cycles to execute on large processors.  So you need to
distinguish between reads and writes, acquires and releases, syncs on
single addresses or general memory syncs.  Big processors are optimised
for throughput, not latency or quick reaction to hardware events.

There are good reasons why big cpus are often paired with a Cortex-M
core in SOCs.

[toc] | [prev] | [next] | [standalone]

#30701

On 6/9/2021 11:59, David Brown wrote:
> On 08/06/2021 22:39, Dimiter_Popoff wrote:
>> On 6/8/2021 23:18, David Brown wrote:
>>> On 08/06/2021 16:46, Theo wrote:
>>>> ......
>>>
>>>> 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 agree with your points and those of Theo, but the cache is basically
>> as wide as the registers? Logically, that is; a cacheline is several
>> times that, probably you refer to that.
>> Not that it makes much of a difference to the fact that 64 bit data
>> buses/registers in an MCU (apart from FPU registers, 32 bit FPUs are
>> useless to me) are unlikely to attract much interest, nothing of
>> significance to be gained as you said.
>> To me 64 bit CPUs are of interest of course and thankfully there are
>> some available, but this goes somewhat past what we call  "embedded".
>> Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
>> there is some real mess with their out of order execution, one needs to
>> do... hmmmm.. "sync", whatever they call it, all the time and there is
>> a huge performance cost because of that. Anybody heard anything about
>> it? (I only know what I was told).
>>
> 
> sync instructions of various types can be needed to handle
> thread/process synchronisation, atomic accesses, and coordination
> between software and hardware registers.  Software normally runs with
> the idea that it is the only thing running, and the cpu can re-order and
> re-arrange the instructions and execution as long as it maintains the
> illusion that the assembly instructions in the current thread are
> executed one after the other.  These re-arrangements and parallel
> execution can give very large performance benefits.
> 
> But it also means that when you need to coordinate with other things,
> you need syncs, perhaps cache flushes, etc.  Full syncs can take
> hundreds of cycles to execute on large processors.  So you need to
> distinguish between reads and writes, acquires and releases, syncs on
> single addresses or general memory syncs.  Big processors are optimised
> for throughput, not latency or quick reaction to hardware events.
> 
> There are good reasons why big cpus are often paired with a Cortex-M
> core in SOCs.
> 
> 

Of course I know all that David, I have been using power processors
which do things out of order for over 20 years now.
What I was told was something about a real mess, like system memory
accesses getting wrong because of out of order execution hence
plenty of syncs needed to keep the thing working. I have not
even tried to verify that, only someone with experience with 64 bit
ARM can do that - so far none here seems to have that.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#30702

On 09/06/2021 20:00, Dimiter_Popoff wrote:
> On 6/9/2021 11:59, David Brown wrote:
>> On 08/06/2021 22:39, Dimiter_Popoff wrote:
>>> On 6/8/2021 23:18, David Brown wrote:
>>>> On 08/06/2021 16:46, Theo wrote:
>>>>> ......
>>>>
>>>>> 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 agree with your points and those of Theo, but the cache is basically
>>> as wide as the registers? Logically, that is; a cacheline is several
>>> times that, probably you refer to that.
>>> Not that it makes much of a difference to the fact that 64 bit data
>>> buses/registers in an MCU (apart from FPU registers, 32 bit FPUs are
>>> useless to me) are unlikely to attract much interest, nothing of
>>> significance to be gained as you said.
>>> To me 64 bit CPUs are of interest of course and thankfully there are
>>> some available, but this goes somewhat past what we call  "embedded".
>>> Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
>>> there is some real mess with their out of order execution, one needs to
>>> do... hmmmm.. "sync", whatever they call it, all the time and there is
>>> a huge performance cost because of that. Anybody heard anything about
>>> it? (I only know what I was told).
>>>
>>
>> sync instructions of various types can be needed to handle
>> thread/process synchronisation, atomic accesses, and coordination
>> between software and hardware registers.  Software normally runs with
>> the idea that it is the only thing running, and the cpu can re-order and
>> re-arrange the instructions and execution as long as it maintains the
>> illusion that the assembly instructions in the current thread are
>> executed one after the other.  These re-arrangements and parallel
>> execution can give very large performance benefits.
>>
>> But it also means that when you need to coordinate with other things,
>> you need syncs, perhaps cache flushes, etc.  Full syncs can take
>> hundreds of cycles to execute on large processors.  So you need to
>> distinguish between reads and writes, acquires and releases, syncs on
>> single addresses or general memory syncs.  Big processors are optimised
>> for throughput, not latency or quick reaction to hardware events.
>>
>> There are good reasons why big cpus are often paired with a Cortex-M
>> core in SOCs.
>>
>>
> 
> Of course I know all that David, I have been using power processors
> which do things out of order for over 20 years now.

It depends on the actual PPC's in question - with single core devices
targeted for embedded systems, you don't need much of that at all.
Perhaps an occasional sync of some sort in connection with using DMA,
but that's about it.  Key to this is, of course, having your MPU set up
right to make sure hardware register accesses are in-order and not cached.

> What I was told was something about a real mess, like system memory
> accesses getting wrong because of out of order execution hence
> plenty of syncs needed to keep the thing working. I have not
> even tried to verify that, only someone with experience with 64 bit
> ARM can do that - so far none here seems to have that.
> 

If the person programming the device has made incorrect assumptions, or
incorrect setup, then yes, things can go wrong if something other than
the current core is affected by the reads or writes.

[toc] | [prev] | [next] | [standalone]

#30703

On 6/9/2021 21:55, David Brown wrote:
> On 09/06/2021 20:00, Dimiter_Popoff wrote:
>> On 6/9/2021 11:59, David Brown wrote:
>>> On 08/06/2021 22:39, Dimiter_Popoff wrote:
>>>> On 6/8/2021 23:18, David Brown wrote:
>>>>> On 08/06/2021 16:46, Theo wrote:
>>>>>> ......
>>>>>
>>>>>> 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 agree with your points and those of Theo, but the cache is basically
>>>> as wide as the registers? Logically, that is; a cacheline is several
>>>> times that, probably you refer to that.
>>>> Not that it makes much of a difference to the fact that 64 bit data
>>>> buses/registers in an MCU (apart from FPU registers, 32 bit FPUs are
>>>> useless to me) are unlikely to attract much interest, nothing of
>>>> significance to be gained as you said.
>>>> To me 64 bit CPUs are of interest of course and thankfully there are
>>>> some available, but this goes somewhat past what we call  "embedded".
>>>> Not long ago in a chat with a guy who knew some of ARM 64 bit I gathered
>>>> there is some real mess with their out of order execution, one needs to
>>>> do... hmmmm.. "sync", whatever they call it, all the time and there is
>>>> a huge performance cost because of that. Anybody heard anything about
>>>> it? (I only know what I was told).
>>>>
>>>
>>> sync instructions of various types can be needed to handle
>>> thread/process synchronisation, atomic accesses, and coordination
>>> between software and hardware registers.  Software normally runs with
>>> the idea that it is the only thing running, and the cpu can re-order and
>>> re-arrange the instructions and execution as long as it maintains the
>>> illusion that the assembly instructions in the current thread are
>>> executed one after the other.  These re-arrangements and parallel
>>> execution can give very large performance benefits.
>>>
>>> But it also means that when you need to coordinate with other things,
>>> you need syncs, perhaps cache flushes, etc.  Full syncs can take
>>> hundreds of cycles to execute on large processors.  So you need to
>>> distinguish between reads and writes, acquires and releases, syncs on
>>> single addresses or general memory syncs.  Big processors are optimised
>>> for throughput, not latency or quick reaction to hardware events.
>>>
>>> There are good reasons why big cpus are often paired with a Cortex-M
>>> core in SOCs.
>>>
>>>
>>
>> Of course I know all that David, I have been using power processors
>> which do things out of order for over 20 years now.
> 
> It depends on the actual PPC's in question - with single core devices
> targeted for embedded systems, you don't need much of that at all.

You *do* need it enough to know what is there to know about it, I have
been through it all. How big a latency there is is irrelevant to the
point.

>> What I was told was something about a real mess, like system memory
>> accesses getting wrong because of out of order execution hence
>> plenty of syncs needed to keep the thing working. I have not
>> even tried to verify that, only someone with experience with 64 bit
>> ARM can do that - so far none here seems to have that.
>>
> 
> If the person programming the device has made incorrect assumptions, or
> incorrect setup, then yes, things can go wrong if something other than
> the current core is affected by the reads or writes.
> 

May be the assumptions of the person were wrong. Or may be your
assumption that their assumptions were wrong is wrong.
Neither of us knows which it is.

Dimiter

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#30681

On 6/8/2021 7:46 AM, 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:
> 
> Register size
> Unit of logical/arithmetical processing
> Memory address/pointer size
> Memory bus/cache width

(General) Register size is the primary driver.

A processor can have very different "size" subcomponents.
E.g., a Z80 is an 8b processor -- registers are nominally 8b.
However, it support 16b operations -- on register PAIRs
(an implicit acknowledgement that the REGISTER is smaller
than the register pair).  This is common on many smaller
processors.  The address space is 16b -- with a separate 16b
address space for I/Os.  The Z180 extends the PHYSICAL
address space to 20b but the logical address space
remains unchanged at 16b (if you want to specify a physical
address, you must use 20+ bits to represent it -- and invoke
a separate mechanism to access it!).  The ALU is *4* bits.

Cache?  Which one?  I or D?  L1/2/3/?

What about the oddballs -- 12b?  1b?

> 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.

That depends on the algorithm chosen and the hardware support available.

> 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.

But you don't buy MCUs with a-la-carte pricing.  How much does an extra
timer cost me?  What if I want it to also serve as a *counter*?  What
cost for 100K of internal ROM?  200K?

[It would be an interesting exercise to try to do a linear analysis of
product prices with an idea of trying to tease out the "costs" (to
the developer) for each feature in EXISTING products!]

Instead, you see a *price* that is reflective of how widely used the
device happens to be, today.  You are reliant on the preferences of others
to determine which is the most cost effective product -- for *you*.

E.g., most of my devices have no "display" -- yet, the MCU I've chosen
has hardware support for same.  It would obviously cost me more to
select a device WITHOUT that added capability -- because most
purchasers *want* a display (and *they* drive the production economies).

I could, potentially, use a 2A03 for some applications.  But, the "TCO"
of such an approach would exceed that of a 32b (or larger) processor!

[What a crazy world!]

> 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
> 

[toc] | [prev] | [next] | [standalone]

#30692

Don Y <blockedofcourse@foo.invalid> wrote:
> On 6/8/2021 7:46 AM, Theo wrote:
> > 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
> 
> (General) Register size is the primary driver.

Is it, though?  What's driving that?
Why do you want larger registers without a larger ALU width?

I don't think register size is of itself a primary pressure.  On larger CPUs
with lots of rename or vector registers, they have kilobytes of SRAM to hold
the registers, and increasing the size is a cost.  On a basic in-order MCU
with 16 or 32 registers, is the register width an issue?  We aren't
designing them on 10 micron technology any more.

I would expect datapath width to be more critical, but again that's
relatively small on an in-order CPU, especially compared with on-chip SRAM.

> However, it support 16b operations -- on register PAIRs
> (an implicit acknowledgement that the REGISTER is smaller
> than the register pair).  This is common on many smaller
> processors.  The address space is 16b -- with a separate 16b
> address space for I/Os.  The Z180 extends the PHYSICAL
> address space to 20b but the logical address space
> remains unchanged at 16b (if you want to specify a physical
> address, you must use 20+ bits to represent it -- and invoke
> a separate mechanism to access it!).  The ALU is *4* bits.

This is not really the world of a current 32-bit MCU, which has a 32 bit
datapath and 32 bit registers.  Maybe it does 64 bit arithmetic in 32 bit
chunks, which then leads to the question of which MCU workloads require 64
bit arithmetic?

> But you don't buy MCUs with a-la-carte pricing.  How much does an extra
> timer cost me?  What if I want it to also serve as a *counter*?  What
> cost for 100K of internal ROM?  200K?
> 
> [It would be an interesting exercise to try to do a linear analysis of
> product prices with an idea of trying to tease out the "costs" (to
> the developer) for each feature in EXISTING products!]
> 
> Instead, you see a *price* that is reflective of how widely used the
> device happens to be, today.  You are reliant on the preferences of others
> to determine which is the most cost effective product -- for *you*.

Sure, what you buy is a 'highest common denominator' - you get things you
don't use, but that other people do.  But it still depends on a significant
chunk of the market demanding those features.  It's then a cost function of
how much the market wants a feature against how much it'll cost to implement
(and at runtime).  If the cost is tiny, it may well get implemented even if
almost nobody asked for it.

If there's a use case, people will pay for it.
(although maybe not enough)

Theo

[toc] | [prev] | [next] | [standalone]

#30693

On 6/9/2021 5:10 AM, Theo wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 6/8/2021 7:46 AM, Theo wrote:
>>> 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
>>
>> (General) Register size is the primary driver.
> 
> Is it, though?  What's driving that?
> Why do you want larger registers without a larger ALU width?

You can use a smaller ALU (in the days when silicon was expensive)
to do the work of a larger one -- if you spread the operation over
time.

> I don't think register size is of itself a primary pressure.  On larger CPUs
> with lots of rename or vector registers, they have kilobytes of SRAM to hold
> the registers, and increasing the size is a cost.  On a basic in-order MCU
> with 16 or 32 registers, is the register width an issue?  We aren't
> designing them on 10 micron technology any more.

It's just how people think of CPU widths.  If there's no cost to
register width, then why didn't 8b CPUs have 64 bit accumulators
(and register files)?

> I would expect datapath width to be more critical, but again that's
> relatively small on an in-order CPU, especially compared with on-chip SRAM.
> 
>> However, it support 16b operations -- on register PAIRs
>> (an implicit acknowledgement that the REGISTER is smaller
>> than the register pair).  This is common on many smaller
>> processors.  The address space is 16b -- with a separate 16b
>> address space for I/Os.  The Z180 extends the PHYSICAL
>> address space to 20b but the logical address space
>> remains unchanged at 16b (if you want to specify a physical
>> address, you must use 20+ bits to represent it -- and invoke
>> a separate mechanism to access it!).  The ALU is *4* bits.
> 
> This is not really the world of a current 32-bit MCU, which has a 32 bit
> datapath and 32 bit registers.

Correct.  I was just illustrating how you can have different
"widths" in a single architecture; yet a single "CPU width"
has to be used to describe it.

> Maybe it does 64 bit arithmetic in 32 bit
> chunks, which then leads to the question of which MCU workloads require 64
> bit arithmetic?

I treat time as a 64b entity (32b being inadequate).
IPv6 addresses won't fit in 32b.
There are also algorithms that can benefit from processing
data in wider chunks (e.g., count the number of set bits
in a 64b array goes faster in a 64b register than on a 32)
My BigRationals would be noticeably faster if I could process
64b at a time, instead of 32.

[This, of course, assumes D cache can hold "as much data" in each
case.]

And you don't always need the full width of a register -- do you use
all 32b of a register when you use it to keep track of the remaining
number of iterations of a loop?  Or, the index into an array?  Or the
time remaining until an upcoming deadline?  Or processing characters
in a string?

>> But you don't buy MCUs with a-la-carte pricing.  How much does an extra
>> timer cost me?  What if I want it to also serve as a *counter*?  What
>> cost for 100K of internal ROM?  200K?
>>
>> [It would be an interesting exercise to try to do a linear analysis of
>> product prices with an idea of trying to tease out the "costs" (to
>> the developer) for each feature in EXISTING products!]
>>
>> Instead, you see a *price* that is reflective of how widely used the
>> device happens to be, today.  You are reliant on the preferences of others
>> to determine which is the most cost effective product -- for *you*.
> 
> Sure, what you buy is a 'highest common denominator' - you get things you
> don't use, but that other people do.  But it still depends on a significant
> chunk of the market demanding those features.

Yes.  Or, an application domain that consumes lots of parts.

>  It's then a cost function of
> how much the market wants a feature against how much it'll cost to implement
> (and at runtime).  If the cost is tiny, it may well get implemented even if
> almost nobody asked for it.

You also have to remember that the seller isn't the sole actor in that
negotiation.  Charge too much and the customer can opt for a different
(possibly "second choice") implementation.

So, it is in the seller's interest to make his product as cost-effectively
as possible.  *Or*, have something that can't be obtained elsewhere.

Nowadays, there are no second sources as there were in decades past.
OTOH, I can find *another* ARM (for example) that may be "close enough"
to what I need and largely compatible with my existing codebase.
So, try to "hold me up" (overcharge) and I may find myself motivated
to visit one of your competitors.

[As HLLs are increasingly used, it's considerably easier to port a
design to a different processor family entirely!  Not so when you had
100K of ASM to leverage]

I worked in a Motogorilla shop, years ago.  When I started my design,
I brought in folks from other vendors.  The Motogorilla rep got spooked;
to lose a design to another house would require answering some serious
questions from his superiors ("How did you lose the account?").  He
was especially nervous that the only Moto offering that I was considering
was second sourced by 7 or 8 other vendors... so, even if the device
got the design, he would likely have competitors keeping his pricing
in line.

> If there's a use case, people will pay for it.
> (although maybe not enough)

Designers often have somewhat arbitrary criteria for their decisions.
Maybe you're looking for something that will be available for at
least a decade.  Or, have alternate sources that could be called upon
in case your fab was compromised or oversold (nothing worse than
hearing parts are "on allocation"!)

So, a vendor can't assume he has the "right" solution (or price) for a
given application.  Maybe the designer has a "history" with a particular
vendor or product line and can leverage that experience in ways that
wouldn't apply to a different vendor.

A vendor's goal should always be to produce the best device for his
perceived/targeted audience at the best price point.  Then, get it
into their hands so they are ready to embrace it when the opportunity
presents.

Microchip took an interesting approach trying to buy into "hobbyists"
with cheap evaluation boards and tools.  I'm sure these were loss leaders.
But, if they ended up winning a design (or two) because the "hobbyist"
was in a position to influence a purchasing decision...

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.arch.embedded

csiph-web