Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30712
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 64-bit embedded computing is here and now |
| Date | 2021-06-09 17:12 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <s9rlf3$3c4$1@dont-email.me> (permalink) |
| References | (3 earlier) <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> |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-07 07:47 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-07 14:13 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-07 22:31 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 07:59 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 00:39 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 13:04 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 17:30 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 09:17 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 03:12 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-12 12:58 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-12 12:40 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 09:41 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 10:12 -0700
Re: 64-bit embedded computing is here and now DJ Delorie <dj@delorie.com> - 2021-06-09 13:16 -0400
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 13:44 -0400
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:03 +0300
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 15:22 -0400
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 12:58 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:26 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 23:12 +0300
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 12:38 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:11 +0200
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 14:25 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-09 00:16 -0400
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:40 +0200
Re: 64-bit embedded computing is here and now Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-06-09 22:52 +0200
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-10 09:37 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 01:01 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:29 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 20:56 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 17:12 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 13:45 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 06:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 18:32 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 14:09 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 01:13 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 21:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 14:14 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 05:10 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 16:35 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 16:24 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-14 05:41 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:51 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-08 18:20 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 18:07 +0100
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 10:34 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:37 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:43 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-08 15:46 +0100
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:18 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-08 23:39 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:33 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:59 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 21:00 +0300
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 20:55 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:06 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:00 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 13:10 +0100
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 06:19 -0700
csiph-web