Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"We came. We saw. We kicked its ass." -- Bill Murray, _Ghostbusters_


devel / comp.arch.embedded / Re: 64-bit embedded computing is here and now

SubjectAuthor
* 64-bit embedded computing is here and nowJames Brakefield
+- Re: 64-bit embedded computing is here and nowDon Y
`* Re: 64-bit embedded computing is here and nowPaul Rubin
 `* Re: 64-bit embedded computing is here and nowDavid Brown
  +* Re: 64-bit embedded computing is here and nowDon Y
  |+* Re: 64-bit embedded computing is here and nowDavid Brown
  ||`* Re: 64-bit embedded computing is here and nowDon Y
  || `* Re: 64-bit embedded computing is here and nowDavid Brown
  ||  +* Re: 64-bit embedded computing is here and nowDon Y
  ||  |`* Re: 64-bit embedded computing is here and nowGeorge Neuner
  ||  | `- Re: 64-bit embedded computing is here and nowDon Y
  ||  `* Re: 64-bit embedded computing is here and nowPaul Rubin
  ||   +- Re: 64-bit embedded computing is here and nowDon Y
  ||   +- Re: 64-bit embedded computing is here and nowDJ Delorie
  ||   `* Re: 64-bit embedded computing is here and nowPhil Hobbs
  ||    `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  ||     `* Re: 64-bit embedded computing is here and nowPhil Hobbs
  ||      +* Re: 64-bit embedded computing is here and nowPaul Rubin
  ||      |`- Re: 64-bit embedded computing is here and nowDon Y
  ||      `- Re: 64-bit embedded computing is here and nowDimiter_Popoff
  |`* Re: 64-bit embedded computing is here and nowJames Brakefield
  | +* Re: 64-bit embedded computing is here and nowDavid Brown
  | |+- Re: 64-bit embedded computing is here and nowJames Brakefield
  | |`* Re: 64-bit embedded computing is here and nowGeorge Neuner
  | | `* Re: 64-bit embedded computing is here and nowDavid Brown
  | |  `* Re: 64-bit embedded computing is here and nowHans-Bernhard Bröker
  | |   `- Re: 64-bit embedded computing is here and nowDavid Brown
  | +* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | |`* Re: 64-bit embedded computing is here and nowDon Y
  | | +* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |`* Re: 64-bit embedded computing is here and nowDon Y
  | | | `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |  `* Re: 64-bit embedded computing is here and nowDon Y
  | | |   `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |    `* Re: 64-bit embedded computing is here and nowDon Y
  | | |     `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |      `* Re: 64-bit embedded computing is here and nowDon Y
  | | |       `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |        `* Re: 64-bit embedded computing is here and nowDon Y
  | | |         `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
  | | |          `- Re: 64-bit embedded computing is here and nowDon Y
  | | `- Re: 64-bit embedded computing is here and nowGeorge Neuner
  | +- Re: 64-bit embedded computing is here and nowDon Y
  | `* Re: 64-bit embedded computing is here and nowPaul Rubin
  |  `* Re: 64-bit embedded computing is here and nowTheo
  |   +* Re: 64-bit embedded computing is here and nowPaul Rubin
  |   |`- Re: 64-bit embedded computing is here and nowDon Y
  |   `- Re: 64-bit embedded computing is here and nowDon Y
  `* Re: 64-bit embedded computing is here and nowTheo
   +* Re: 64-bit embedded computing is here and nowDavid Brown
   |`* Re: 64-bit embedded computing is here and nowDimiter_Popoff
   | +- Re: 64-bit embedded computing is here and nowDon Y
   | `* Re: 64-bit embedded computing is here and nowDavid Brown
   |  `* Re: 64-bit embedded computing is here and nowDimiter_Popoff
   |   `* Re: 64-bit embedded computing is here and nowDavid Brown
   |    `- Re: 64-bit embedded computing is here and nowDimiter_Popoff
   `* Re: 64-bit embedded computing is here and nowDon Y
    `* Re: 64-bit embedded computing is here and nowTheo
     `- Re: 64-bit embedded computing is here and nowDon Y

Pages:123
Re: 64-bit embedded computing is here and now

<s9qf6m$8fb$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=515&group=comp.arch.embedded#515

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 06:19:58 -0700
Organization: A noiseless patient Spider
Lines: 142
Message-ID: <s9qf6m$8fb$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Jun 2021 13:20:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="67e6bc2a74bcfde539b04c3da972b629";
logging-data="8683"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/IiW7qa1SXuykPj6D9sHPZ"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:xY88a9WqRWEvup1c4u1dQjPaAak=
In-Reply-To: <vXB*SVcmy@news.chiark.greenend.org.uk>
Content-Language: en-US
 by: Don Y - Wed, 9 Jun 2021 13:19 UTC

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

Re: 64-bit embedded computing is here and now

<87r1hb2doq.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=516&group=comp.arch.embedded#516

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 09 Jun 2021 09:41:25 -0700
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <87r1hb2doq.fsf@nightsong.com>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8a612fa17c2e7dd40cbaf9074acabd0e";
logging-data="18310"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+xvXxX1uyW1ao4VY86r7Og"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:vhJkW0PwsKdBCpsvOQTBZOdeqhs=
sha1:vqsYM7tpi2ieS8RCY57MLXx0J08=
 by: Paul Rubin - Wed, 9 Jun 2021 16:41 UTC

David Brown <david.brown@hesbynett.no> writes:
> I can't really tell what kinds of designs you are discussing here. When
> I talk about embedded systems in general, I mean microcontrollers
> running specific programs - not general-purpose computers in embedded
> formats (such as phones).

Philip Munts made a comment a while back that stayed with me: that these
days, in anything mains powered, there is usually little reason to use
an MCU instead of a Linux board.

Re: 64-bit embedded computing is here and now

<wXB*B1dmy@news.chiark.greenend.org.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=517&group=comp.arch.embedded#517

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.nntp4.net!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!.POSTED!not-for-mail
From: theom+n...@chiark.greenend.org.uk (Theo)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: 09 Jun 2021 18:07:58 +0100 (BST)
Organization: University of Cambridge, England
Lines: 23
Message-ID: <wXB*B1dmy@news.chiark.greenend.org.uk>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com> <87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me> <s9n6rb$t19$1@dont-email.me> <5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com> <87czsvesvs.fsf@nightsong.com>
NNTP-Posting-Host: chiark.greenend.org.uk
X-Trace: chiark.greenend.org.uk 1623258480 21330 212.13.197.229 (9 Jun 2021 17:08:00 GMT)
X-Complaints-To: abuse@chiark.greenend.org.uk
NNTP-Posting-Date: Wed, 9 Jun 2021 17:08:00 +0000 (UTC)
User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/3.16.0-7-amd64 (x86_64))
Originator: theom@chiark.greenend.org.uk ([212.13.197.229])
 by: Theo - Wed, 9 Jun 2021 17:07 UTC

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

Re: 64-bit embedded computing is here and now

<s9qsqi$ftr$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=518&group=comp.arch.embedded#518

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 10:12:20 -0700
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <s9qsqi$ftr$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Jun 2021 17:12:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="67e6bc2a74bcfde539b04c3da972b629";
logging-data="16315"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+bETaVDjErDug+qkpJ7m9n"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:Fiyog6cOqIS8gnd1S7rv2TypsCE=
In-Reply-To: <87r1hb2doq.fsf@nightsong.com>
Content-Language: en-US
 by: Don Y - Wed, 9 Jun 2021 17:12 UTC

On 6/9/2021 9:41 AM, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> I can't really tell what kinds of designs you are discussing here. When
>> I talk about embedded systems in general, I mean microcontrollers
>> running specific programs - not general-purpose computers in embedded
>> formats (such as phones).
>
> Philip Munts made a comment a while back that stayed with me: that these
> days, in anything mains powered, there is usually little reason to use
> an MCU instead of a Linux board.

I note that anytime you use a COTS "module" of any kind, you're still
stuck having to design and layout some sort of "add-on" card that
handles your specific I/O needs; few real world devices can be
controlled with just serial ports, NICs and "storage interfaces".

And, you're now dependant on a board supplier as well as having
to understand what's on (and in) that board as they are now
critical components of YOUR product. The same applies to any firmware
or software that it runs.

I'm sure the FAA, FDA, etc. will gladly allow you to formally
validate some other party's software and assume responsibility
for its proper operation!

Re: 64-bit embedded computing is here and now

<xnsg1r557m.fsf@delorie.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=519&group=comp.arch.embedded#519

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 09 Jun 2021 12:16:13 -0500
From: dj...@delorie.com (DJ Delorie)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
Date: Wed, 09 Jun 2021 13:16:13 -0400
Message-ID: <xnsg1r557m.fsf@delorie.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:gAuob+Jw/qOiHPdOqNz2vKgAo3Q=
MIME-Version: 1.0
Content-Type: text/plain
Lines: 13
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-3sI+C6oRktTxArHuNgxkjHYJ4jOvnCpu+l+EnwrVWkmBYrDFSULylWAwaPqyea75iuBBcL0PW4Y97Jb!i6l9bAQUMlOVzcnNK/5o+KwazTuocdNd4AX0KskMHzjd/w9pyg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 1841
 by: DJ Delorie - Wed, 9 Jun 2021 17:16 UTC

Paul Rubin <no.email@nospam.invalid> writes:
> Philip Munts made a comment a while back that stayed with me: that these
> days, in anything mains powered, there is usually little reason to use
> an MCU instead of a Linux board.

I have a friend who has a ceiling fan with a raspberry pi in it, because
that was the easiest solution to turning it on and off remotely...

So yeah, I agree, "with a computer" is becoming a default answer.

On the other hand, my furnace (now geothermal) has been controlled by a
linux board since 2005 or so... maybe I'm not the typical user ;-)

Re: 64-bit embedded computing is here and now

<87eedbeybw.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=520&group=comp.arch.embedded#520

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 09 Jun 2021 10:34:43 -0700
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <87eedbeybw.fsf@nightsong.com>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<87czsvesvs.fsf@nightsong.com> <wXB*B1dmy@news.chiark.greenend.org.uk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8a612fa17c2e7dd40cbaf9074acabd0e";
logging-data="9248"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19t0pCOj9NqlRQLA3SVisQ5"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:P6Wegz1VxaGNUUP/afp+aQgQCo0=
sha1:2q87JJevR/Mgyc3oPLwqFswrlLg=
 by: Paul Rubin - Wed, 9 Jun 2021 17:34 UTC

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.

Re: 64-bit embedded computing is here and now

<42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=521&group=comp.arch.embedded#521

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 09 Jun 2021 12:44:13 -0500
Subject: Re: 64-bit embedded computing is here and now
Newsgroups: comp.arch.embedded
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com> <87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me> <s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me> <s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me> <87r1hb2doq.fsf@nightsong.com>
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Message-ID: <42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
Date: Wed, 9 Jun 2021 13:44:11 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87r1hb2doq.fsf@nightsong.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 29
X-Trace: sv3-OvjEJD4v32ul9KcnJXeO/8HH5TDOMfAr1Ddy0WzHhOb/zPBjPwzOhqLpiywGtU397DPJ/Rl4qP0QD2z!e1g0IJMfvpto4Vm5c9mlmUPPGPZWbAhKpoF1mN34vv9pNlbTsUkQaiGfeiwhgA0pcsDk+JGCeGTi!6NQd2ZRM4m99pnoRzegs+g==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2337
 by: Phil Hobbs - Wed, 9 Jun 2021 17:44 UTC

Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> I can't really tell what kinds of designs you are discussing here. When
>> I talk about embedded systems in general, I mean microcontrollers
>> running specific programs - not general-purpose computers in embedded
>> formats (such as phones).
>
> Philip Munts made a comment a while back that stayed with me: that these
> days, in anything mains powered, there is usually little reason to use
> an MCU instead of a Linux board.
>

Except that if it has a network connection, you have to patch it
unendingly or suffer the common-as-dirt IoT security nightmares.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: 64-bit embedded computing is here and now

<s9qvc9$1nu$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=522&group=comp.arch.embedded#522

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 20:56:23 +0300
Organization: TGI
Lines: 42
Message-ID: <s9qvc9$1nu$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 17:56:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bc8b6acb1416ddd781bfd8aa807a1e3a";
logging-data="1790"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/doOfCtRomhBRJOI3K3MClMVITo81H8xo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:giNcZgfvkoh0yp3j/giVjBsh1Gk=
In-Reply-To: <s9p5ie$fsu$1@dont-email.me>
Content-Language: en-US
 by: Dimiter_Popoff - Wed, 9 Jun 2021 17:56 UTC

On 6/9/2021 4:29, Don Y 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.

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

There is *nothing* to gain on a 64 bit machine from segmentation,
assigning overlapping address spaces to tasks etc.

Notice I am talking *logical* addresses, I was explicit about
that.

Dimiter

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

Re: 64-bit embedded computing is here and now

<s9qvji$1nu$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=523&group=comp.arch.embedded#523

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 21:00:17 +0300
Organization: TGI
Lines: 67
Message-ID: <s9qvji$1nu$2@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<Iyz*Vc+ly@news.chiark.greenend.org.uk> <s9ojag$4ce$1@dont-email.me>
<s9okhu$e58$1@dont-email.me> <s9pvth$b1c$1@dont-email.me>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 18:00:18 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bc8b6acb1416ddd781bfd8aa807a1e3a";
logging-data="1790"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Fu/GffhW6grDApBxyaLQ5l7Ev7ZKZuWU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:J/U5tONJxz/EwXMNCCEiB1p93Rs=
In-Reply-To: <s9pvth$b1c$1@dont-email.me>
Content-Language: en-US
 by: Dimiter_Popoff - Wed, 9 Jun 2021 18:00 UTC

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/

Re: 64-bit embedded computing is here and now

<s9r2qi$4k3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=524&group=comp.arch.embedded#524

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 20:55:13 +0200
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <s9r2qi$4k3$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<Iyz*Vc+ly@news.chiark.greenend.org.uk> <s9ojag$4ce$1@dont-email.me>
<s9okhu$e58$1@dont-email.me> <s9pvth$b1c$1@dont-email.me>
<s9qvji$1nu$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 18:55:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="31128722c11e3449d2f369f962ae6707";
logging-data="4739"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/DzM9pO3zjKYb3DDVizCbV3+MVCO9hBUU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:vZqm82s41zgIeTBJG/lSAMcRNuk=
In-Reply-To: <s9qvji$1nu$2@dont-email.me>
Content-Language: en-GB
 by: David Brown - Wed, 9 Jun 2021 18:55 UTC

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.

Re: 64-bit embedded computing is here and now

<s9r39l$dnu$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=525&group=comp.arch.embedded#525

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 22:03:15 +0300
Organization: TGI
Lines: 34
Message-ID: <s9r39l$dnu$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
<42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 19:03:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bc8b6acb1416ddd781bfd8aa807a1e3a";
logging-data="14078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+p5/UPC9xg1iVsVZCxM19ML0NYq3U5uCc="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:IJX0sqP6E+T6AVmLIBZOqmIfm9s=
In-Reply-To: <42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
Content-Language: en-US
 by: Dimiter_Popoff - Wed, 9 Jun 2021 19:03 UTC

On 6/9/2021 20:44, Phil Hobbs wrote:
> Paul Rubin wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> I can't really tell what kinds of designs you are discussing here.  When
>>> I talk about embedded systems in general, I mean microcontrollers
>>> running specific programs - not general-purpose computers in embedded
>>> formats (such as phones).
>>
>> Philip Munts made a comment a while back that stayed with me: that these
>> days, in anything mains powered, there is usually little reason to use
>> an MCU instead of a Linux board.
>>
>
> Except that if it has a network connection, you have to patch it
> unendingly or suffer the common-as-dirt IoT security nightmares.
>
> Cheers
>
> Phil Hobbs
>

Those nightmares do not apply if you are in complete control of your
firmware - which few people are nowadays indeed.

I have had netMCA devices on the net for over 10 years now in many
countries, the worst problem I have seen was some Chinese IP hanging
on port 80 to no consequences.

Dimiter

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

Re: 64-bit embedded computing is here and now

<s9r3gd$hte$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=526&group=comp.arch.embedded#526

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 22:06:51 +0300
Organization: TGI
Lines: 90
Message-ID: <s9r3gd$hte$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<Iyz*Vc+ly@news.chiark.greenend.org.uk> <s9ojag$4ce$1@dont-email.me>
<s9okhu$e58$1@dont-email.me> <s9pvth$b1c$1@dont-email.me>
<s9qvji$1nu$2@dont-email.me> <s9r2qi$4k3$1@dont-email.me>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 19:06:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bc8b6acb1416ddd781bfd8aa807a1e3a";
logging-data="18350"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rhrPaUIzb8AeKjFbYyMO9b/2W5XCaHw0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:l753/dfat87Wse5/a0ZcPnFkOc0=
In-Reply-To: <s9r2qi$4k3$1@dont-email.me>
Content-Language: en-US
 by: Dimiter_Popoff - Wed, 9 Jun 2021 19:06 UTC

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/

Re: 64-bit embedded computing is here and now

<935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=527&group=comp.arch.embedded#527

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 09 Jun 2021 14:22:34 -0500
Subject: Re: 64-bit embedded computing is here and now
Newsgroups: comp.arch.embedded
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com> <87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me> <s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me> <s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me> <87r1hb2doq.fsf@nightsong.com> <42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net> <s9r39l$dnu$1@dont-email.me>
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Message-ID: <935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>
Date: Wed, 9 Jun 2021 15:22:32 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <s9r39l$dnu$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 47
X-Trace: sv3-1xiZr77mAdrh52x5Qr/X9DcrsG9ywPF4OQiy/O9VkKQpkZUAT8mrwqvcCI8aEjvG61L57L85XrSpWpU!a8k0kAH7a08vCjnYAIb5O0gKWxHkzq9YdctDAgUb7rvnpuaEHeqChCW8T7TO2fADoCOCWNO+fEup!hEWQYDvVatVUj9uGsCJmjg==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3100
 by: Phil Hobbs - Wed, 9 Jun 2021 19:22 UTC

Dimiter_Popoff wrote:
> On 6/9/2021 20:44, Phil Hobbs wrote:
>> Paul Rubin wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> I can't really tell what kinds of designs you are discussing here.
>>>> When
>>>> I talk about embedded systems in general, I mean microcontrollers
>>>> running specific programs - not general-purpose computers in embedded
>>>> formats (such as phones).
>>>
>>> Philip Munts made a comment a while back that stayed with me: that these
>>> days, in anything mains powered, there is usually little reason to use
>>> an MCU instead of a Linux board.
>>>
>>
>> Except that if it has a network connection, you have to patch it
>> unendingly or suffer the common-as-dirt IoT security nightmares.
>>
>
> Those nightmares do not apply if you are in complete control of your
> firmware - which few people are nowadays indeed.
>
> I have had netMCA devices on the net for over 10 years now in many
> countries, the worst problem I have seen was some Chinese IP hanging
> on port 80 to no consequences.

But if you're using a RasPi or Beaglebone or something like that, you
need a reasonably well-upholstered Linux distro, which has to be patched
regularly. At very least it'll need a kernel, and kernel patches
affecting security are not exactly rare.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: 64-bit embedded computing is here and now

<87wnr2kdxo.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=528&group=comp.arch.embedded#528

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 09 Jun 2021 12:58:43 -0700
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <87wnr2kdxo.fsf@nightsong.com>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
<42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
<s9r39l$dnu$1@dont-email.me>
<935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8a612fa17c2e7dd40cbaf9074acabd0e";
logging-data="32290"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19SgEEw8+4F05nsWDhQ3uE9"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Cancel-Lock: sha1:TNj1YtxayrQUNAMDGfhFDmwI+vY=
sha1:RSgUB7jdHNYSs2KcK0vsZ3jNvG8=
 by: Paul Rubin - Wed, 9 Jun 2021 19:58 UTC

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:
> But if you're using a RasPi or Beaglebone or something like that, you
> need a reasonably well-upholstered Linux distro, which has to be
> patched regularly. At very least it'll need a kernel, and kernel
> patches affecting security are not exactly rare.

You're in the same situation with almost anything else connected to the
internet. Think of the notorious "smart light bulbs".

On the other hand, you are in reasonable shape if the raspberry pi
running your fish tank is only reachable through a LAN or VPN.
Non-networked low end linux boards are also a thing.

Re: 64-bit embedded computing is here and now

<s9r7c2$td4$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=529&group=comp.arch.embedded#529

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 23:12:48 +0300
Organization: TGI
Lines: 59
Message-ID: <s9r7c2$td4$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
<42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
<s9r39l$dnu$1@dont-email.me>
<935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jun 2021 20:12:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bc8b6acb1416ddd781bfd8aa807a1e3a";
logging-data="30116"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/R0VhjqyH8nhfXCuQNDfhWNlpiWZGuLG0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:m89QcD9Eq9AMeFlTg0y8OACNBhs=
In-Reply-To: <935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>
Content-Language: en-US
 by: Dimiter_Popoff - Wed, 9 Jun 2021 20:12 UTC

On 6/9/2021 22:22, Phil Hobbs wrote:
> Dimiter_Popoff wrote:
>> On 6/9/2021 20:44, Phil Hobbs wrote:
>>> Paul Rubin wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> I can't really tell what kinds of designs you are discussing here.
>>>>> When
>>>>> I talk about embedded systems in general, I mean microcontrollers
>>>>> running specific programs - not general-purpose computers in embedded
>>>>> formats (such as phones).
>>>>
>>>> Philip Munts made a comment a while back that stayed with me: that
>>>> these
>>>> days, in anything mains powered, there is usually little reason to use
>>>> an MCU instead of a Linux board.
>>>>
>>>
>>> Except that if it has a network connection, you have to patch it
>>> unendingly or suffer the common-as-dirt IoT security nightmares.
>>>
>>
>> Those nightmares do not apply if you are in complete control of your
>> firmware - which few people are nowadays indeed.
>>
>> I have had netMCA devices on the net for over 10 years now in many
>> countries, the worst problem I have seen was some Chinese IP hanging
>> on port 80 to no consequences.
>
> But if you're using a RasPi or Beaglebone or something like that, you
> need a reasonably well-upholstered Linux distro, which has to be patched
> regularly.  At very least it'll need a kernel, and kernel patches
> affecting security are not exactly rare.
>
> Cheers
>
> Phil Hobbs
>
>
>

Oh if you use one of these all you can rely on is prayer, I don't
think there is *one* person knowing everything which goes on within
such a system. Basically it is impossible to know, even if you have
all the manpower to dissect all the code you can still be taken by
surprise by something a compiler has inserted somewhere etc., your
initial point is well taken here.
If you ask *me* if I am 100% sure what my devices might do - and I
have written every single bit of code running on them, which has
been compiled by a compiler I have written every single bit of - I
might still be scratching my head. We buy our silicon, you know...

Dimiter

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

Re: 64-bit embedded computing is here and now

<iicnvpFd8f7U1@mid.dfncis.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=530&group=comp.arch.embedded#530

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail
From: HBBroe...@t-online.de (Hans-Bernhard Bröker)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 22:52:06 +0200
Lines: 29
Message-ID: <iicnvpFd8f7U1@mid.dfncis.de>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9oit7$1mi$1@dont-email.me> <doc0cgdq9hclq231h0fpiks5nka58iee16@4ax.com>
<s9puq6$oce$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.dfncis.de qQwpronBo5YJjRCyNXzq5Q19KZaGSN3Zn/0XpAhBhypQSBgfAlrtcgQvhu
Cancel-Lock: sha1:lKARcBkXvlVqDG+8bbAWIr+eoOk=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
In-Reply-To: <s9puq6$oce$1@dont-email.me>
Content-Language: en-US
 by: Hans-Bernhard Bröke - Wed, 9 Jun 2021 20:52 UTC

Am 09.06.2021 um 10:40 schrieb David Brown:
> On 09/06/2021 06:16, George Neuner wrote:

>> Since (at least) the Pentium 4 x86 really are a CISC decoder bolted
>> onto the front of what essentially is a load/store RISC.

.... and at about that time they also abandoned the last traces of their
original von-Neumann architecture. The actual core is quite strictly
Harvard now, treating the external RAM banks more like mass storage
devices than an actual combined code+data memory.

> Absolutely. But from the user viewpoint, it is the ISA that matters -

That depends rather a lot on who gets to be called the "user".

x86 are quite strictly limited to the PC ecosystem these days: boxes and
laptops built for Mac OS or Windows, some of them running Linux instead.
There the "user" is somebody buying hardware and software from
completely unrelated suppliers. I.e. unlike in the embedded world we
discuss here, the persons writing software for those things had no say
at all what type of CPU is used. They're thus not really the "user."
If they were, they probably wouldn't be using an x86. ;-)

The actual x86 users couldn't care less about the ISA --- the
overwhelming majority of them haven't the slightest idea what an ISA
even is. Some of them used to have a vague idea that there was some
32bit vs. a 64bit whatchamacallit somewhere in there, but even that has
surely faded away by now, as users no longer even face the decision
between them.

Re: 64-bit embedded computing is here and now

<s9rin6$hr6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=531&group=comp.arch.embedded#531

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 16:26:06 -0700
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <s9rin6$hr6$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me> <s9nir0$k47$1@dont-email.me>
<s9p24n$tp2$1@dont-email.me> <s9ppv5$vn3$1@dont-email.me>
<87r1hb2doq.fsf@nightsong.com>
<42552ef9-05d2-24b9-66c3-c7da93720218@electrooptical.net>
<s9r39l$dnu$1@dont-email.me>
<935eb1da-2454-e167-5e43-eded02d4c0bf@electrooptical.net>
<87wnr2kdxo.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Jun 2021 23:26:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="18278"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/+xYfuhQrWCOTYVF18JHQE"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:plhz6cW30C0Mlt+ZPfC1C0dMxXo=
In-Reply-To: <87wnr2kdxo.fsf@nightsong.com>
Content-Language: en-US
 by: Don Y - Wed, 9 Jun 2021 23:26 UTC

On 6/9/2021 12:58 PM, Paul Rubin wrote:
> Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:
>> But if you're using a RasPi or Beaglebone or something like that, you
>> need a reasonably well-upholstered Linux distro, which has to be
>> patched regularly. At very least it'll need a kernel, and kernel
>> patches affecting security are not exactly rare.
>
> You're in the same situation with almost anything else connected to the
> internet. Think of the notorious "smart light bulbs".

No, that's only if you didn't adequately prepare for such "exposure".

How many Linux/Windows boxes are running un-NEEDED services? Have
ports open that shouldn't be? How much emphasis was spent on ekeing
out a few percent extra performance from the network stack that
could have, instead, been spent on making it more robust?

How many folks RUNNING something like Linux/Windows in their product
actually know much of anything about what's under the hood? Do they
even know how to BUILD a kernel, let alone sort out what it's
doing (wrong)?

Exposed to the 'net you always are at the mercy of DoS attacks
consuming your inbound bandwidth (assuming you have no contrtol
of upstream traffic/routing). But, even a saturated network
connection doesn't have to crash your device.

OTOH, if your box is dutifully trying to respond to incoming packets
that may be malicious, then you'd better hope that response is
"correct" (or at least SAFE) in EVERY case.

For any of these mainstream OS's, an adversary can play with an
exact copy of yours 24/7/365 to determine its vulnerabilities
before ever approaching your device. And, even dig through
the sources (of some) to see how a potential attack could unfold.
Your device will likely advertise exactly what version of the
kernel (and network stack) it is running.

[An adversary can also BUY one of YOUR devices and do the same
off-line analysis -- but the analysis will only apply to YOUR
device (if you have a proprietary OS/stack) and not a
multitude of other exposed devices]

> On the other hand, you are in reasonable shape if the raspberry pi
> running your fish tank is only reachable through a LAN or VPN.
> Non-networked low end linux boards are also a thing.

Exactly. But that limits utility/accessibility.

If you only need moderate/occasional access, you can implement
a "stealth mode" that lets the server hide, "unprotected".
Or, require all accesses to be initiated from that server
(*to* the remote client) -- similar to a call-back modem.

And, of course, you can place constraints on what can be done
over that connection instead of just treating it as "God Mode".
[No, you can't set the heat to 105 degrees in the summer time;
I don't care if you happen to have appropriate credentials!
And, no, you can't install an update without my verifying
you and the update through other mechanisms...]

Re: 64-bit embedded computing is here and now

<s9rjcg$tl3$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=532&group=comp.arch.embedded#532

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 16:37:24 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <s9rjcg$tl3$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<87czsvesvs.fsf@nightsong.com> <wXB*B1dmy@news.chiark.greenend.org.uk>
<87eedbeybw.fsf@nightsong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Jun 2021 23:37:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="30371"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YHEAa7Dh9PLPxg09d4u0B"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:BpKakX8VUhrGooFoulPrng53Czs=
In-Reply-To: <87eedbeybw.fsf@nightsong.com>
Content-Language: en-US
 by: Don Y - Wed, 9 Jun 2021 23:37 UTC

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.

Re: 64-bit embedded computing is here and now

<s9rjnm$498$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=533&group=comp.arch.embedded#533

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 16:43:25 -0700
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <s9rjnm$498$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<87czsvesvs.fsf@nightsong.com> <wXB*B1dmy@news.chiark.greenend.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Jun 2021 23:43:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="4392"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FZVTtTBcC41kxbbcDvZSH"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:jDlAH1dO5yfSGQpR3GtusXD0vYs=
In-Reply-To: <wXB*B1dmy@news.chiark.greenend.org.uk>
Content-Language: en-US
 by: Don Y - Wed, 9 Jun 2021 23:43 UTC

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! ;-)

Re: 64-bit embedded computing is here and now

<s9rlf3$3c4$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=534&group=comp.arch.embedded#534

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Wed, 9 Jun 2021 17:12:57 -0700
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <s9rlf3$3c4$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
<s9qvc9$1nu$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Jun 2021 00:13:23 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="3460"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19op1JJMFmQhBHcHaMgrnyq"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:cqulNgAVTJATgKCrh7U1R8dGEYQ=
In-Reply-To: <s9qvc9$1nu$1@dont-email.me>
Content-Language: en-US
 by: Don Y - Thu, 10 Jun 2021 00:12 UTC

On 6/9/2021 10:56 AM, Dimiter_Popoff wrote:
> On 6/9/2021 4:29, Don Y 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.
>
> 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).

I can share code between tasks without conflicting addressing;
the "data" for one instance of the app is isolated from other
instances while the code is untouched -- the code doesn't even
need to know that it is being invoked on different "data"
from one timeslice to the next. In a flat address space,
you'd need the equivalent of a "context pointer" that you'd
have to pass to the "shared code". And, have to hope that
all of your context could be represented in a single such
reference! (I can rearrange physical pages so they each
appear "where expected" to a bit of const CODE).

Similarly, the data passed (or shared) from one task (process) to
another can "appear" at entirely different logical addresses
"at the same time" as befitting the needs of each task WITHOUT
CONCERN (or awareness) of the existence of the other task.
Again, I don't need to pass a pointer to the data; the address
space has been manipulated to make sure it's where it should be.

The needs of a task can be met by resources "harvested" from
some other task. E.g., where is the stack for your TaskA?
How large is it? How much of it is in-use *now*? How much
can it GROW before it bumps into something (because that something
occupies space in "its" address space).

I start a task (thread) with a single page of stack. And, a
limit on how much it is allowed to consume during its execution.
Then, when it pushes something "off the end" of that page,
I fault a new page in and map it at the faulting address.
This continues as the task's stack needs grow.

When I run out of available pages, I do a GC cycle to
reclaim pages from (other?) tasks that are no longer using
them.

In this way, I can effectively SHARE a stack (or heap)
between multiple tasks -- without having to give any
consideration for where, in memory, they (or the stacks!)
reside.

I can move a page from one task (full of data) to another
task at some place that the destination task finds "convenient".
I can import a page from another network device or export
one *to* another device.

Because each task's address space is effectively empty/sparse,
mapping a page doesn't require much effort to find a "free"
place for it.

I can put constraints on each such mapping -- and then runtime
checks to ensure "things are as I expect": "Why is this NIC
buffer residing in this particular portion of the address space?"

With a task bound to a semicontiguous portion of memory, it can
deal with that region as if it was a smaller virtual region.
I can store 32b pointers to things if I know that my addresses
are based from 0x000 and the task never extends beyond a 4GB
region. If available, I can exploit "shorter" addressing modes.

> There is *nothing* to gain on a 64 bit machine from segmentation, assigning
> overlapping address spaces to tasks etc.

What do you gain by NOT using it? You're still dicking with the MMU.
(if you aren't then what value the MMU in your "logical" space? map
each physical page to a corresponding logical page and never talk to
the MMU again; store const page tables and let your OS just tweek the
base pointer for the TLBs to use for THIS task)

You still have to "position" physical resources in particular places
(and you have to deal with the constraints of all tasks, simultaneously,
instead of just those constraints imposed by the "current task")

> Notice I am talking *logical* addresses, I was explicit about
> that.

Re: 64-bit embedded computing is here and now

<s9sfg4$qfn$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=535&group=comp.arch.embedded#535

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Thu, 10 Jun 2021 09:37:40 +0200
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <s9sfg4$qfn$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9oit7$1mi$1@dont-email.me> <doc0cgdq9hclq231h0fpiks5nka58iee16@4ax.com>
<s9puq6$oce$1@dont-email.me> <iicnvpFd8f7U1@mid.dfncis.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Jun 2021 07:37:40 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="749cb4c4a83b68a919d63fd9db1d9263";
logging-data="27127"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18yFUYQCTxi2VVwIgqpYuDeKyTnzl4mpRI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
Cancel-Lock: sha1:Sp6sEdfuoE0aCYyxRuNs/NqJsP0=
In-Reply-To: <iicnvpFd8f7U1@mid.dfncis.de>
Content-Language: en-GB
 by: David Brown - Thu, 10 Jun 2021 07:37 UTC

On 09/06/2021 22:52, Hans-Bernhard Bröker wrote:
> Am 09.06.2021 um 10:40 schrieb David Brown:
>> On 09/06/2021 06:16, George Neuner wrote:
>
>>> Since (at least) the Pentium 4 x86 really are a CISC decoder bolted
>>> onto the front of what essentially is a load/store RISC.
>
> ... and at about that time they also abandoned the last traces of their
> original von-Neumann architecture.  The actual core is quite strictly
> Harvard now, treating the external RAM banks more like mass storage
> devices than an actual combined code+data memory.
>
>> Absolutely.  But from the user viewpoint, it is the ISA that matters -
>
> That depends rather a lot on who gets to be called the "user".
>

I meant "the person using the ISA" - i.e., the programmer. And even
then, I meant low-level programmers who have to understand things like
memory models, cache thrashing, coding for vectors and SIMD, etc. These
are the people who see the ISA. I was not talking about the person
wiggling the mouse and watching youtube!

Re: 64-bit embedded computing is here and now

<s9sqgv$1l6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=536&group=comp.arch.embedded#536

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Thu, 10 Jun 2021 13:45:49 +0300
Organization: TGI
Lines: 161
Message-ID: <s9sqgv$1l6$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
<s9qvc9$1nu$1@dont-email.me> <s9rlf3$3c4$1@dont-email.me>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Jun 2021 10:45:51 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="831e72849d16303c5d2d20d75d8b5880";
logging-data="1702"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VtcqTDHufpxM1yk0oq9jOpQOs4KYLFD0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:KjE+3yBIYRM1g6l+g0kHyeVqjlU=
In-Reply-To: <s9rlf3$3c4$1@dont-email.me>
Content-Language: en-US
 by: Dimiter_Popoff - Thu, 10 Jun 2021 10:45 UTC

On 6/10/2021 3:12, Don Y wrote:
> On 6/9/2021 10:56 AM, Dimiter_Popoff wrote:
>> On 6/9/2021 4:29, Don Y 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.
>>
>> 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).

Nothing could be further from the truth. What kind of crippled
environment can make you think that? Code can be position
independent on processors which are not dead by design nowadays.
When I started dps some 27 years ago I allowed program modules
to demand a fixed address on which they would reside. This exists
to this day and has been used 0 (zero) times. Same about object
descriptors, program library modules etc., the first system call
I wrote is called "allocm$", allocate memory. You request a number
of bytes and you get back an address and the actual number of
bytes you were given (it comes rounded by the memory cluster
size, typically 4k (a page). This was the *first* thing I did.
And yes, all allocation is done using worst fit strategy, sometimes
enhanced worst fit - things the now popular OS-s have yet to get to,
they still have to defragment their disks, LOL.

>
> I can share code between tasks without conflicting addressing;
> the "data" for one instance of the app is isolated from other
> instances while the code is untouched -- the code doesn't even
> need to know that it is being invoked on different "data"
> from one timeslice to the next.  In a flat address space,
> you'd need the equivalent of a "context pointer" that you'd
> have to pass to the "shared code".  And, have to hope that
> all of your context could be represented in a single such
> reference!  (I can rearrange physical pages so they each
> appear "where expected" to a bit of const CODE).
>
> Similarly, the data passed (or shared) from one task (process) to
> another can "appear" at entirely different logical addresses
> "at the same time" as befitting the needs of each task WITHOUT
> CONCERN (or awareness) of the existence of the other task.
> Again, I don't need to pass a pointer to the data; the address
> space has been manipulated to make sure it's where it should be.

So how do you pass the offset from the page beginning if you do
not pass an address.
And how is page manipulation simpler and/or safer than just passing
an address, sounds like a recipe for quite a mess to me.
In a 64 bit address space there is nothing stopping you to
pass addresses or not passing them and allow access to areas
you want to and disallow it elsewhere.
Other than that there is nothing to be gained by a 64 bit architecture
really, on 32 bit machines you do have FPUs, vector units etc.
doing calculation probably faster than the integer unit of a
64 bit processor.
The *whole point* of a 64 bit core is the 64 bit address space.

>
> The needs of a task can be met by resources "harvested" from
> some other task.  E.g., where is the stack for your TaskA?
> How large is it?  How much of it is in-use *now*?  How much
> can it GROW before it bumps into something (because that something
> occupies space in "its" address space).

This is the beauty of 64 bit logical address space. You allocate
enough logical memory and then you allocate physical on demand,
this is what MMUs are there for. If you want to grow your stack
indefinitely - the messy C style - you can just allocate it
a few gigabytes of logical memory and use the first few kilobytes
of it to no waste of resources. Of course there are much slicker
ways to deal with memory allocation.

>
> I start a task (thread) with a single page of stack.  And, a
> limit on how much it is allowed to consume during its execution.
> Then, when it pushes something "off the end" of that page,
> I fault a new page in and map it at the faulting address.
> This continues as the task's stack needs grow.

This is called "allocate on demand" and has been around
for times immemorial, check my former paragraph.

>
> When I run out of available pages, I do a GC cycle to
> reclaim pages from (other?) tasks that are no longer using
> them.

This is called "memory swapping", also for times immemorial.
For the case when there is no physical memory to reclaim, that
is.
The first version of dps - some decades ago - ran on a CPU32
(a 68340). It had no MMU so I implemented "memory blocks",
a task can declare a piece a swap-able block and allow/disallow
its swapping. Those blocks would then be shared or written to disk when
more memory was needed etc., memory swapping without an MMU.
Worked fine, must be still working for code I have not
touched since on my power machines, all those decades later.

>
> In this way, I can effectively SHARE a stack (or heap)
> between multiple tasks -- without having to give any
> consideration for where, in memory, they (or the stacks!)
> reside.

You can do this in a linear address space, too - this is what
the MMU is for.

>
> I can move a page from one task (full of data) to another
> task at some place that the destination task finds "convenient".
> I can import a page from another network device or export
> one *to* another device.

So instead of simply passing an address you have to switch page
translation entries, adjust them on each task switch, flush and
sync whatever it takes - does not sound very efficient to me.

>
> Because each task's address space is effectively empty/sparse,
> mapping a page doesn't require much effort to find a "free"
> place for it.

This is the beauty of having the 64 bit address space, you always
have enough logical memory. The "64 bit address space per task"
buys you *nothing*.

Dimiter

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

Re: 64-bit embedded computing is here and now

<s9t5ku$fd5$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=537&group=comp.arch.embedded#537

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Thu, 10 Jun 2021 06:55:16 -0700
Organization: A noiseless patient Spider
Lines: 327
Message-ID: <s9t5ku$fd5$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
<s9qvc9$1nu$1@dont-email.me> <s9rlf3$3c4$1@dont-email.me>
<s9sqgv$1l6$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Jun 2021 13:55:43 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="15781"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+OTB5OJKYA4iBxLtglh88A"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:9+e40WOUAtYvnHf4+XcWHInW7vk=
In-Reply-To: <s9sqgv$1l6$1@dont-email.me>
Content-Language: en-US
 by: Don Y - Thu, 10 Jun 2021 13:55 UTC

On 6/10/2021 3:45 AM, Dimiter_Popoff wrote:

[attrs elided]

>>>>> 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).
>
> Nothing could be further from the truth. What kind of crippled
> environment can make you think that? Code can be position
> independent on processors which are not dead by design nowadays.
> When I started dps some 27 years ago I allowed program modules
> to demand a fixed address on which they would reside. This exists
> to this day and has been used 0 (zero) times. Same about object
> descriptors, program library modules etc., the first system call
> I wrote is called "allocm$", allocate memory. You request a number
> of bytes and you get back an address and the actual number of
> bytes you were given (it comes rounded by the memory cluster
> size, typically 4k (a page). This was the *first* thing I did.
> And yes, all allocation is done using worst fit strategy, sometimes
> enhanced worst fit - things the now popular OS-s have yet to get to,
> they still have to defragment their disks, LOL.

You missed my point -- possibly because this issue was raised
BEFORE pointing out how much DYNAMIC management of the MMU
(typically an OS delegated acticity) "buys you":
"That depends on what you expect from the OS."

If you can ignore the MMU *completely*, then the OS is greatly
simplified. YOU (developer) take on the responsibilites of remembering
what is where, etc. EVERYTHING is visible to EVERYONE and at
EVERYTIME. The OS doesn't have to get involved in the management
of objects/tasks/etc. That's YOUR responsibility to ensure
your taskA doesn't go dicking around with taskB's resources.

Welcome to the 8/16b world!

The next step up is to statically deploy the MMU. You build
a SINGLE logical address space to suit your liking. Then, map
the underlying physical resources to it as best fits. And,
this never needs to change -- memory doesn't "move around",
it doesn't change characteristics (readable, writeable,
exeuctable, accessable-by-X, etc.)!

But, you can't then change permissions based on which task is
executing -- unless you want to dick with the MMU dynamically
(or swap between N discrete sets of STATIC page tables that
define the many different ways M tasks can share permissions)

So, you *just* use the MMU as a Memory Protection Unit; you mark
sections of memory that have CODE in them as no-write, you mark
regions with DATA as no-execute, and everything else as no-access.

And that's the way it stays for EVERY task!

This lets you convert RAM to ROM and prevents "fetches" from "DATA"
memory. It ensures your code is never overwritten and that the
processor never tries to execute out of "data memory" and NOTHING
tries to access address regions that are "empty"!

You've implemented a 1980's vintage protection scheme (this is how
we designed arcade pieces, back then, as you wanted your CODE
and FRAME BUFFER to occupy the same limited range of addresses)

<yawn>

Once you start using the MMU to dynamically *manage* memory (which
includes altering protections and re-mapping), then the cost of the
OS increases -- because these are typically things that are delegated
*to* the OS.

Whether or not you have overlapping address spaces or a single
flat address space is immaterial -- you need to dynamically manage
separate page tables for each task in either scheme. You can't
argue that the OS doesn't need to dick with the MMU "because it's
a flat address space" -- unless you forfeit those abilities
(that I illustrated in my post).

If you want to compare a less-able OS to one that is more featured,
then its disingenuous to blame that on overlapping address spaces;
the real "blame" lies in the support of more advanced features.

The goal of an OS should be to make writing *correct* code easier
by providing features as enhancements. It's why the OS typically
reads disk files instead of replicating that file system and driver
code into each task that needs to do so. Or, why it implements
delays/timers -- so each task doesn't reinvent the wheel (with its
own unique set of bugs).

You can live without an OS. But, typically only for a trivial
application. And, you're not likely to use a 64b processor just
to count characters received on a serial port! Or as an egg timer!

>> I can share code between tasks without conflicting addressing;
>> the "data" for one instance of the app is isolated from other
>> instances while the code is untouched -- the code doesn't even
>> need to know that it is being invoked on different "data"
>> from one timeslice to the next. In a flat address space,
>> you'd need the equivalent of a "context pointer" that you'd
>> have to pass to the "shared code". And, have to hope that
>> all of your context could be represented in a single such
>> reference! (I can rearrange physical pages so they each
>> appear "where expected" to a bit of const CODE).
>>
>> Similarly, the data passed (or shared) from one task (process) to
>> another can "appear" at entirely different logical addresses
>> "at the same time" as befitting the needs of each task WITHOUT
>> CONCERN (or awareness) of the existence of the other task.
>> Again, I don't need to pass a pointer to the data; the address
>> space has been manipulated to make sure it's where it should be.
>
> So how do you pass the offset from the page beginning if you do
> not pass an address.

YOU pass an object to the OS and let the OS map it where *it*
wants, with possible hints from the targeted task (logical address
space).

I routinely pass multiple-page-sized objects around the system.

"Here's a 20MB telephone recording, memory mapped (to wherever YOU,
its recipient, want it). Because it is memory mapped and has its
own pager, the actual amount of physical memory that is in use
at any given time can vary -- based on the resource allocation
you've been granted and the current resource availability in the
system. E.g., there may be as little as one page of physical
data present at any given time -- and that page may "move" to
back a different logical address based on WHERE you are presently
looking!

Go through and sort out when Bob is speaking and when Tom is speaking.
"Return" an object of UNKNOWN length that lists each of these time
intervals along with the speaker assumed to be talking in each. Tell
me where you (the OS) decided it would best fit into my logical address
space, after consulting the hint I provided (but that you may not have
been able to honor because the result ended up *bigger* than the "hole"
I had imagined it fitting into). No need to tell me how big it really
is as I will be able to parse it (cuz I know how you will have built that
list) and the OS will track the memory that it uses so all I have to do
is free() it (it may be built out of 1K pages, 4K pages, 16MB pages)!"

How is this HARDER to do when a single task has an entire 64b address
space instead of when it has to SHARE *a* single address space among
all tasks/objects?

> And how is page manipulation simpler and/or safer than just passing
> an address, sounds like a recipe for quite a mess to me.

The MMU has made that mapping a "permanent" part of THIS task's
address space. It isn't visible to any other task -- why *should*
it be? Why does the pointer need to indirectly reflect the fact
that portions of that SINGLE address space are ineligible to
contain said object because of OTHER unrelated (to this task) objects??

> In a 64 bit address space there is nothing stopping you to
> pass addresses or not passing them and allow access to areas
> you want to and disallow it elsewhere.

And I can't do that in N overlapping 64b address spaces?


Click here to read the complete article
Re: 64-bit embedded computing is here and now

<s9tba9$pmh$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=538&group=comp.arch.embedded#538

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: dp...@tgi-sci.com (Dimiter_Popoff)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Thu, 10 Jun 2021 18:32:23 +0300
Organization: TGI
Lines: 51
Message-ID: <s9tba9$pmh$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
<s9qvc9$1nu$1@dont-email.me> <s9rlf3$3c4$1@dont-email.me>
<s9sqgv$1l6$1@dont-email.me> <s9t5ku$fd5$1@dont-email.me>
Reply-To: dp@tgi-sci.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Jun 2021 15:32:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="831e72849d16303c5d2d20d75d8b5880";
logging-data="26321"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+qOoZlP88mmRZ6xCzXffyIciFyBNEbDQM="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:tC2DSn09Z0q2EXiMsmebKiHArDQ=
In-Reply-To: <s9t5ku$fd5$1@dont-email.me>
Content-Language: en-US
 by: Dimiter_Popoff - Thu, 10 Jun 2021 15:32 UTC

On 6/10/2021 16:55, Don Y wrote:
> On 6/10/2021 3:45 AM, Dimiter_Popoff wrote:
>
> [attrs elided]
>
Don, this becomes way too lengthy and repeating itself.

You keep on saying that a linear 64 bit address space means exposing
everything to everybody after I explained this is not true at all.

You keep on claiming this or that about how I do things without
bothering to understand what I said - like your claim that I use the MMU
for "protection only".
NO, this is not true either. On 32 bit machines - as mine in
production are - mapping 4G logical space into say 128M of physical
memory goes all the way through page translation, block translation
for regions where page translation would be impractical etc.
You sound the way I would have sounded before I had written and
built on for years what is now dps. The devil is in the detail :-).

You pass "objects", pages etc. Well guess what, it *always* boils
down to an *address* for the CPU. The rest is generic talk.
And if you choose to have overlapping address spaces when you
pass a pointer from one task to another the OS has to deal with this
at a significant cost.
In a linear address space, you pass the pointer *as is* so the OS does
not have to deal with anything except access restrictions.
In dps, you can send a message to another task - the message being
data the OS will copy into that tasks memory, the data being
perfectly able to be an address of something in another task's
memory. If a task accesses an address it is not supposed to
the user is notified and allowed to press CR to kill that task.
Then there are common data sections for groups of tasks etc.,
it is pretty huge really.

The concept "one entire address space to all tasks" is from the 60-s
if not earlier (I just don't know and don't care to check now) and it
has done a good job while it was necessary, mostly on 16 bit CPUs.
For today's processors this means just making them run with the
handbrake on, *nothing* is gained because of that - no more security
(please don't repeat that "expose everything" nonsense), just
burning more CPU power, constantly having to remap addresses etc.

Dimiter

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

Re: 64-bit embedded computing is here and now

<s9tv2l$1ub$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=539&group=comp.arch.embedded#539

 copy link   Newsgroups: comp.arch.embedded
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: blockedo...@foo.invalid (Don Y)
Newsgroups: comp.arch.embedded
Subject: Re: 64-bit embedded computing is here and now
Date: Thu, 10 Jun 2021 14:09:22 -0700
Organization: A noiseless patient Spider
Lines: 236
Message-ID: <s9tv2l$1ub$1@dont-email.me>
References: <7eefb5db-b155-44f8-9aad-7ce25d06c602n@googlegroups.com>
<87lf7kexbp.fsf@nightsong.com> <s9n10p$t4i$1@dont-email.me>
<s9n6rb$t19$1@dont-email.me>
<5e77ea0a-ef41-4f72-a538-4edc9bfff075n@googlegroups.com>
<s9opbi$gtu$1@dont-email.me> <s9p5ie$fsu$1@dont-email.me>
<s9qvc9$1nu$1@dont-email.me> <s9rlf3$3c4$1@dont-email.me>
<s9sqgv$1l6$1@dont-email.me> <s9t5ku$fd5$1@dont-email.me>
<s9tba9$pmh$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Jun 2021 21:09:41 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="220cc8c27fff3a84ffe6cfd2eb61a952";
logging-data="1995"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+L52Rh8K7qfDTuXVK2GuRz"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.1
Cancel-Lock: sha1:slMGYqK58YWsA4PQTzIA7x3b5x4=
In-Reply-To: <s9tba9$pmh$1@dont-email.me>
Content-Language: en-US
 by: Don Y - Thu, 10 Jun 2021 21:09 UTC

On 6/10/2021 8:32 AM, Dimiter_Popoff wrote:
> On 6/10/2021 16:55, Don Y wrote:
>> On 6/10/2021 3:45 AM, Dimiter_Popoff wrote:
>>
>> [attrs elided]
> >
> Don, this becomes way too lengthy and repeating itself.
>
> You keep on saying that a linear 64 bit address space means exposing
> everything to everybody after I explained this is not true at all.

Task A has built a structure -- a page worth of data residing
at 0x123456. It wants to pass this to TaskB so that TaskB can perform
some operations on it.

Can TaskB acccess the data at 0x123456 *before* TaskA has told it
to do so?

Can TaskB access the data at 0x123456 WHILE TaskA is manipulating it?

Can TaskA alter the data at 0x123456 *after* it has "passed it along"
to TaskB -- possibly while TaskB is still using it?

> You keep on claiming this or that about how I do things without
> bothering to understand what I said - like your claim that I use the MMU
> for "protection only".

I didn't say that YOU did that. I said that to be able to ignore
the MMU after setting it up, you can ONLY use it to protect
code from alteration, data from execution, etc. The "permissions"
that it applies have to be invariant over the execution time of
ALL of the code.

So, if you DON'T use it "for protection only", then you are admitting
to having to dynamically tweek it.

*THIS* is the cost that the OS incurs -- and having a flat address
space doesn't make it any easier! If you aren't incurring that cost,
then you're not protecting something.

> NO, this is not true either. On 32 bit machines - as mine in
> production are - mapping 4G logical space into say 128M of physical
> memory goes all the way through page translation, block translation
> for regions where page translation would be impractical etc.
> You sound the way I would have sounded before I had written and
> built on for years what is now dps. The devil is in the detail :-).
>
> You pass "objects", pages etc. Well guess what, it *always* boils
> down to an *address* for the CPU. The rest is generic talk.

Yes, the question is "who manages the protocol for sharing".
Since forever, you could pass pointers around and let anyone
access anything they wanted. You could impose -- but not
ENFORCE -- schemes that ensured data was shared properly
(e.g., so YOU wouldn't be altering data that *I* was using).

[Monitors can provide some structure to that sharing but
are costly when you consider the number of things that may
potentially need to be shared. And, you can still poke
directly at the data being shared, bypassing the monitor,
if you want to (or have a bug)]

But, you had to rely on programming discipline to ensure this
worked. Just like you have to rely on discipline to ensure
code is "bugfree" (how's that worked for the industry?)

> And if you choose to have overlapping address spaces when you
> pass a pointer from one task to another the OS has to deal with this
> at a significant cost.

How does your system handle the above example? How do you "pass" the
pointer from TaskA to TaskB -- if not via the OS? Do you expose a
shared memory region that both tasks can use to exchange data
and hope they follow some rules? Always use synchronization
primitives for each data exchange? RELY on the developer to
get it right? ALWAYS?

Once you've passed the pointer, how does TaskB access that data
WITHOUT having to update the MMU? Or, has TaskB had access to
the data all along?

What happens when B wants to pass the modified data to C?
Does the MMU have to be updated (C's tables) to grant that
access? Or, like B, has C had access all along? And, has
C had to remain disciplined enough not to go mucking around
with that region of memory until A *and* B have done modifying
it?

I don't allow anyone to see anything -- until the owner of that thing
explicitly grants access. If you try to access something before it's
been made available for your access, the OS traps and aborts your
process -- you've violated the discipline and the OS is going to
enforce it! In an orderly manner that doesn't penalize other
tasks that have behaved properly.

> In a linear address space, you pass the pointer *as is* so the OS does
> not have to deal with anything except access restrictions.
> In dps, you can send a message to another task - the message being
> data the OS will copy into that tasks memory, the data being
> perfectly able to be an address of something in another task's

So, you don't use the MMU to protect TaskA's resources from TaskB
(or TaskC!) access. You expect LESS from your OS.

> memory. If a task accesses an address it is not supposed to
> the user is notified and allowed to press CR to kill that task.

What are the addresses "it's not supposed to?" Some *subset* of
the addresses that "belong" to other tasks? Perhaps I can
access a buffer that belongs to TaskB but not TaskB's code?
Or, some OTHER buffer that TaskB doesn't want me to see? Do
you explicitly have to locate ("org") each buffer so that you
can place SOME in protected portions of the address space and
others in shared areas? How do you change these distinctions
dynamically -- or, do you do a lot of data copying from
"protected" space to "shared" space?

> Then there are common data sections for groups of tasks etc.,
> it is pretty huge really.

Again, you expose things by default -- even if only a subset
of things. You create shared memory regions where there are
no protections and then rely on your application to behave and
not access data (that has been exposed for its access) until
it *should*.

Everybody does this. And everyone has bugs as a result. You
are relying on the developer to *repeatedly* implement the sharing
protocol -- instead of relying on the OS to enforce that for you.

It's like putting tons of globals in your application -- to
make data sharing easier (and, thus, more prone to bugs).

You expect less of your OS.

My tasks are free to do whatever they want in their own protection domain.
They KNOW that nothing can SEE the data they are manipulating *or*
observe HOW they are manipulating it or *influence* their manipulation
of it.

Until they want to expose that data. And, then, only to those entities
that they think SHOULD see it.

They can give (hand-off) data to another entity -- much like call-by-value
semantics -- and have the other entity know that NOTHING that the
original "donor" can do AFTER that handoff will affect the data that
has been "passed" to them.

Yet, they can still manipulate that data -- update it or reuse that
memory region -- for the next "client".

The OS enforces these guarantees. Much more than just passing along
a pointer to the data! Trying to track down the donor's alteration
of data while the recipient is concurrently accessing it (multiple
tasks, multiple cores, multiple CPUs) is a nightmare proposition.
And, making an *unnecessary* copy of it is a waste of resources
(esp if the two parties actually ARE well-behaved)

> The concept "one entire address space to all tasks" is from the 60-s
> if not earlier (I just don't know and don't care to check now) and it
> has done a good job while it was necessary, mostly on 16 bit CPUs.
> For today's processors this means just making them run with the
> handbrake on, *nothing* is gained because of that - no more security
> (please don't repeat that "expose everything" nonsense), just
> burning more CPU power, constantly having to remap addresses etc.

Remapping is done in hardware. The protection overhead is a
matter of updating page table entries. *You* gain nothing by creating
a flat address space because *you* aren't trying to compartmentalize
different tasks and subsystems. You likely protect the kernel's
code/data from direct interference from "userland" (U/S bit) but
want the costs of sharing between tasks to be low -- at the expense
of forfeiting protections between them.

*Most* of the world consists of imperfect coders. *Most* of us have
to deal with colleagues (of varying abilities) before, after and
during our tenure running code on the same CPU as our applications.

"The bug is (never!) in my code! So, it MUST be in YOURS!"

You can either stare at each other, confident in the correctness
of your own code. Or, find the bug IN THE OTHER GUY'S CODE
(you can't prove yours is correct anymore than he can; so you have to
find the bug SOMEWHERE to make your point), effectively doing his
debugging *for* him.

Why do you think desktop OS's go to such lengths to compartmentalize
applications? Aren't the coders of application A just as competent
as those who coded application B? Why would you think application
A might stomp on some resource belonging to application B? Wouldn't
that be a violation of DISCIPLINE (and outright RUDE)?


Click here to read the complete article
Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor