From: "Svein E. Seldal" <Svein.Seldal@solidas.com>
To: Denis Chertykov <denisc@overta.ru>
Cc: gcc@gcc.gnu.org
Subject: Re: [RFC] Gcc and harvard architectures (towards AVR)
Date: Thu, 19 Dec 2002 06:07:00 -0000 [thread overview]
Message-ID: <3E01A731.3060800@solidas.com> (raw)
In-Reply-To: <8yyo5t8f.fsf@localhost.localdomain>
Denis Chertykov wrote:
>>I have a technical suggestion for how to implement this, but I would
>>like to discuss the issue in a general basis before entering the
>>detailed discussion.
>
>
> Look to archive.
> Subject: Segment register support for the i386
> Date: 31 Dec 1999
Yes, I've seen this before. But it still is an unresolved issue IMHO.
For the avr-gcc this is a obvious limiation, as it required more
resources to do something that is simpler if gcc had the page support.
My suggestion is as follows:
A target has two address-spaces; the data (the default) and the code.
Consider the following example:
Accesses to the data-space is done as normal:
int a = 1234; // Declares a data storeage in data-space
int *p = &a; // Declare a pointer (in data-space) to a data-space
// storeage
x = *p; // Will fill x with 1234
Accesses using the code-space can be done as follows:
(Please note that code-space is usually read-only, and for this to work
you'd have to declare the variables and pointers as const - but I'll
skip this for now)
// Declare a datastoreage in code-space
int __attribute__((codespace)) b = 5678;
// Declare a pointer in data-space which points to a code-space
// address
int __attribute__((codespace)) * q = &b;
// Declare a pointer in code-space which points to a code-space
// address
int __attribute__((codespace)) * __attribute__((codespace)) r = &b;
// Will read the contents of the code-space datastorage 'b' and
// place it into x, which in this example is 5678
x = *q;
// This will fail because 'q' is a codespace pointer, while 'p' is
// dataspace pointer
q = p;
*) For those familiar with the avr target this is the same as the
'progmem' attribute. I just want to use the codespace name as a
demostration of how to do it.
Would this be a feasable implemenation of address-spaces?
What global (gcc) changes would a implementation like this imply?
Svein
next prev parent reply other threads:[~2002-12-19 11:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-17 9:57 Svein E. Seldal
2002-12-17 12:23 ` Denis Chertykov
2002-12-19 6:07 ` Svein E. Seldal [this message]
2002-12-19 22:47 ` Richard Henderson
2002-12-24 2:21 ` [RFC] Gcc and multiple memory spaces (former Gcc and harvard architectures (towards AVR)) Svein E. Seldal
2002-12-28 2:33 ` devik
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=3E01A731.3060800@solidas.com \
--to=svein.seldal@solidas.com \
--cc=denisc@overta.ru \
--cc=gcc@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).