Re: Gforth and gcc "progress"
- From: anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
- Date: Fri, 29 Jun 2007 16:09:37 GMT
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:....
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Some of the other things you mention are likely to be viewed by gcc
maintainers as not a bug, in particular the practice of taking code
fragments that gcc has generated and copying them elsewhere. I would
find it very hard to defend a patch for that.
In general it's hard to support. For example, PC-relative references
to constant data will break.
I am not asking the gcc maintainers to help us about PC-relative
references (that would be cool, too, but that's a different issue),
just to avoid reordering basic blocks.
Some targets need this such references
to load large integer constants, some don't.
I have never encountered a platform where this is the case. Many
platforms do position-independent code using a global pointer, and use
that to load large integer constants (Alpha, PPC, MIPS); AMD64 uses
PC-relative references to access global variables, but has an inline
instruction for large integer constants (so no need to use PC-relative
references for large integer constants).
So, as long as we avoid global variables and relative calls and other
relative branches to code outside the unit of copying, we are fine in
may experience. Global variables can be worked around (although help
from the compiler would be appreciated); calls are not a problem for
us and there's a workaround for that, too; relative branches we can
mostly control through source code, if the compiler keeps the code in
the same order, and that's why we want that feature.
So, if there were to be a proper definition of what the compiler needs
to do to support this technique, then it could be made into a
documented extension, and then gcc would have to support it. I am
very strongly opposed to gcc informally supporting an undocumented
extension.
So, do you want me and maybe some other concerned parties to write up
a proper definition?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
.
- Follow-Ups:
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- References:
- Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Re: Gforth and gcc "progress"
- From: Anton Ertl
- Re: Gforth and gcc "progress"
- From: Andrew Haley
- Gforth and gcc "progress"
- Prev by Date: Re: Gforth and gcc "progress"
- Next by Date: Re: Gforth and gcc "progress"
- Previous by thread: Re: Gforth and gcc "progress"
- Next by thread: Re: Gforth and gcc "progress"
- Index(es):
Relevant Pages
|