Re: Gforth and gcc "progress"

Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
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.

OK, that is reasonable.

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.

I have. It was quite tricky too, because the PC-relative load range
was only a few kybytes, so we couldn't simply put all the constants at
the end of the function. Instead, we had to look for a nearby
unconditional branch after which to put the data. If there wasn't one
we had to insert one.

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

Yes, I see.

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?

No, because I do not think it would be accepted.

Andrew.
.

Relevant Pages

  • Re: math.nroot [was Re: A brief question.]
    ... > so before VC 7.1 was released (C99 ain't exactly new anymore). ... > support _some_ way to get at this stuff. ... This includes gcc before C99 ... > and fenv.h -- if the platforms represented in fpectlmodule.c were ...
    (comp.lang.python)
  • Re: Idea: Multitasking graphical OS for the GS
    ... IIgs 65816 compiler that has nearly the number of ... gcc also has a much larger support infrastructure where it will be easier to ... The software developer and the hardware ...
    (comp.sys.apple2)
  • Re: Compiling Tcl with Msys/MinGW on Windows XP
    ... checking for gcc... ... checking whether the C compiler is a cross-compiler... ... checking for EXCEPTION_DISPOSITION support in include files... ... I saw one case were people had to use msys 1.0.6 ...
    (comp.lang.tcl)
  • Re: C is too old? opinions?
    ... You insisted that this pragma is supported by many compilers, ... I cannot find any mention of it in the documentation for my current gcc ... If they support if, it is undocumented and probably deprecated. ... And, of course, the bar software worked fine. ...
    (comp.lang.c)
  • Re: Non ASCII characters in CFString litteral, HELP !
    ... Same for icc ... CodeWarrior is PPC-only and very dead, ... compilers listed don't even support Objective-C. ... For this particular case, blame C or Cocoa, not gcc. ...
    (comp.sys.mac.programmer.help)