From: david.brown@hesbynett.no   
      
   On 06/11/2025 12:21, bart wrote:   
   > On 06/11/2025 07:51, David Brown wrote:   
   >> On 05/11/2025 16:15, Scott Lurndal wrote:   
   >>> David Brown  writes:   
   >>>> On 04/11/2025 23:04, Scott Lurndal wrote:   
   >>>>> David Brown  writes:   
   >>>>>> On 04/11/2025 18:32, Scott Lurndal wrote:   
   >>>>>   
   >>>>>> .  (And I have never   
   >>>>>> seen a Cortex-M device with programmable windows or addresses -   
   >>>>>> indeed,   
   >>>>>> I believe the Cortex-M core documentation specifies some memory   
   >>>>>> ranges   
   >>>>>> explicitly.   
   >>>>>   
   >>>>> I have used Cortex-M devices with programmable windows   
   >>>>> in the physical address space.   
   >>>>   
   >>>> OK.  I have not, but I haven't used the newer Cortex-M cores as yet, so   
   >>>> it could well be a new feature.   
   >>>   
   >>> It is not necessarily a feature of the M7 core itself, but rather   
   >>> the glue logic around it - particularly the logic that interfaces   
   >>> to the "system bus" to which the M7 core is interfaced.   That logic   
   >>> is under the control of the SoC designer and can easily have   
   >>> external registers that are programmed to specify how to route   
   >>> accesses from the M7, including to large regions of DRAM;   
   >>> consider a maintenance processor on a 64-bit server that needs   
   >>> access to the server DRAM space for RAS purposes.   
   >>>   
   >>   
   >> Fair enough, now I see what you are getting at.  Yes, once you are   
   >> outside the Cortex-M core and key ARM-supplied components (like the   
   >> interrupt controller), you as a SoC designer are free to do what you   
   >> like.  And if you have a 32-bit processor that needs access to a   
   >> 64-bit address space, you are going to have to do some kind of   
   >> windowing or segmenting.   
   >>   
   >> In the SoC's I have used where 64-bit Cortex-A processors are combined   
   >> with a Cortex-M core for security purposes, booting, or for better   
   >> real- time control of peripherals, the Cortex-M device does not have   
   >> direct access to the 64-bit memory space.  It has access to the   
   >> peripherals, some dedicated memory, and a message-passing interface   
   >> with the Cortex-A cores.   
   >>   
   >> But in your work, you probably see more variety and more possibilities   
   >> for these things - I only get to use the chips someone else has made!   
   >>   
   >   
   > I think you were right, if this 'M7' chip doesn't directly have   
   > registers, instructions or infrastructure to access the more complex   
   > memory system.   
   >   
   > Unless you are modifying M7 itself, then that 'glue' logic could be   
   > applied to anything (eg. I've built a Z80 system with 256KB RAM), and it   
   > is that composite system that a language + compiler can target.   
   >   
   > Then it would appear to the use of the language that the target machine   
   > had those extended features. But if they were to look at the generated   
   > code, they might see it was accessing external registers or whatever.   
   >   
   > So it's cheating.   
      
   You were fine up until the last sentence here.  What do you mean by   
   "cheating" ?  Whose rules is it breaking?  The system Scott was   
   describing (assuming I understood him correctly) let the 32-bit core   
   access blocks of the 64-bit address space.  You can choose which part of   
   the address space is accessible at any given time (presumably by   
   accessing segment or window registers like any other memory-mapped   
   peripheral registers).  But you can't call it "cheating" unless you have   
   defined some set of rules for what is "allowed" and what is not allowed,   
   and everyone else has agreed to play by those rules.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)