Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30693
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 64-bit embedded computing is here and now |
| Date | 2021-06-09 06:19 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <s9qf6m$8fb$1@dont-email.me> (permalink) |
| References | (1 earlier) <87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me> <Iyz*Vc+ly@news.chiark.greenend.org.uk> <s9osrt$5fa$1@dont-email.me> <vXB*SVcmy@news.chiark.greenend.org.uk> |
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...
Back to comp.arch.embedded | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web