All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francesco VIRLINZI <francesco.virlinzi@st.com>
To: linux-sh@vger.kernel.org
Subject: Re: On "sh: Consolidate SH-Mobile CPU code in arch/sh/kernel/cpu/shmobile/."
Date: Wed, 18 Mar 2009 14:17:14 +0000	[thread overview]
Message-ID: <49C1026A.3040308@st.com> (raw)
In-Reply-To: <49BF4B7C.2090607@st.com>

Hi Magnus
>> For this reason in the interpreter there is no real instruction 'data'
>> oriented...
>> Each interpreter instruction works with the i-th element of an k-th
>> ioresources.
>>     
>
> So you may pass the base address of some hardware block as a resource,
> and then use offset from the base address to get to registers inside
> the hardware block. Or did I misunderstand?
>   
No you didn't. You are right the interpreter can manage registers inside 
the hardware block.
> I'd go with fixed sized operations where one operation is maximum one
> cache line. And the first part of each operation has an instruction
> that just does a jump to the beginning of the next operation (next or
> same cache line). This jumping will go on until a magic end operation
> is reached. That's how I would preload the operations.
>   
Ok.
> Each operation has two entry points, one for preloading and another
> one for running the actual code.
>
> Together with this we need code that generates the operations for us.
> A bit like a relocator or linker. I imagine that each operation is
> implemented in assembly, and data needed by the operation is located
> in the end at a fixed offset from the beginning of the operation. Then
> we have C functions that just copies the code into a destination
> address and fills in the data with whatever needed.
>
> And for each processor or board we have some code that calls the C
> functions that generates the operations for us. The argument to these
> functions can be anything.
>
> A bit like QEMU. =)
>
>
> Wouldn't a 32-bit pointer work well for you?
>   
Yes
> So basically I'd like to get rid of the your resource + offset
> abstraction and go with regular addresses. What do you think?
>   
The main reason of 'resource + offset' was due on a different PMB usage 
model in our kernel.
But more probably with your "relocator - linker" at runtime I should be 
able to close every issue.


Do you have already some stuff/prototype?
Regards
 Framcescp

  parent reply	other threads:[~2009-03-18 14:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  7:04 On "sh: Consolidate SH-Mobile CPU code in arch/sh/kernel/cpu/shmobile/." Francesco VIRLINZI
2009-03-17  7:15 ` Paul Mundt
2009-03-17 10:35 ` Francesco VIRLINZI
2009-03-17 11:31 ` Magnus Damm
2009-03-17 14:43 ` Francesco VIRLINZI
2009-03-18  9:53 ` Magnus Damm
2009-03-18 14:17 ` Francesco VIRLINZI [this message]
2009-03-19  5:39 ` Magnus Damm
2009-03-19  7:17 ` Francesco VIRLINZI
2009-03-23 10:29 ` Magnus Damm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49C1026A.3040308@st.com \
    --to=francesco.virlinzi@st.com \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.