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: Tue, 17 Mar 2009 14:43:18 +0000 [thread overview]
Message-ID: <49BFB706.8020004@st.com> (raw)
In-Reply-To: <49BF4B7C.2090607@st.com>
Hi Magnus
>
> Sure. Let's do it step by step. I like the idea of some kind of
> interpreter, but I was hoping on that we can agree on something a bit
> simpler.
If possible why not
>
> My main question is: Do you really need to be able to load and save
> data from the interpreter?
This isn't really a problem or an issue.
The current code work mainly with only 2 tables:
- an instruction table
- a resource table
The resource table is an array of base address of usable resource, it
doesn't matter what the resource is... each
resource can be hw or memory... the writable table (in my convention)
is only the first element of
ioresource table.
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.
In the code I have only to be care the 'writable' table is in Dcache...
but after that
for the interpreter point of vie the writable table and an hw-resource
are perfectly equivalent.
>
> Right now your implementation has multiple tables.
> I'd prefer to just
> generate a bunch of inline operations that we either load into the
> cache or put in on-chip ram depending on processor type. Each
> operation would be self-contained.
I agree and for this reason I wrote several macros on top of
instructions to simplify the
table creation, but I'd like maintain the current granularity because
'ad-hoc' instruction
could be too much hw dependent and we could need to add other asm code
to support
any new hw... While with this instruction granularity a new hw means at
least
some other macro to build the right instruction the new hw needs.
>
> What are your requirements?
In the ST40 we have no ipref instruction and in the latest version it
was removed the
RAM mode cache support.
Therefore the code has to be preloaded in Icache with the jumper
mechanism I did (other suggestion?)
Moreover I don't want set constraint on how many resource the
interpreter can use.
This means that the interpreter should be able to manage (teorically)
any hw resource not only the dram,
for example I strongly need access the Clocks-IP.
Regards
Francesco
next prev parent reply other threads:[~2009-03-17 14:43 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 [this message]
2009-03-18 9:53 ` Magnus Damm
2009-03-18 14:17 ` Francesco VIRLINZI
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=49BFB706.8020004@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox