Re: Gforth and gcc "progress"



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/
.



Relevant Pages

  • Re: RISC OS modules with stock gcc?
    ... if you don't use any global variables ISTR they're ... I've done some playing with gcc, and I've *nearly* gotten it all working ... if gcc decides there's a static relationship between r10 ... my choices are now either to copy all the const data into the ...
    (comp.sys.acorn.programmer)
  • Re: Newbie question
    ... If you want to have whatever C99 gcc already has, ... > which will enable you to run the ddd debugger but it must be installed ... You are declaring a global variable emp. ... Read up on this and the structural dangers of using global variables. ...
    (comp.lang.c)
  • Re: Gforth and gcc "progress"
    ... fragments that gcc has generated and copying them elsewhere. ... other relative branches to code outside the unit of copying, ... and then gcc would have to support it. ...
    (comp.lang.forth)
  • Problem building on BeOS...
    ... the Python preprocessing balks on the "\" line continuation ... Is it just that my version of gcc is not ... Apps that do not need to be compiled install and run fine. ... not copying Lib/LinearAlgebra.py ...
    (comp.lang.python)