Re: GCC front-end for FORTH?
- From: Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 31 Oct 2007 10:31:11 -0000
Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
Anton Ertl <anton@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Andrew Haley <andrew29@xxxxxxxxxxxxxxxxxxxxxxx> writes:
To generate code for DUP, for example, you'd do
more or less the same as generating C from Forth and then compiling
that. You'd generate something like:
sp--; *sp = tos;
Come on, you know better. Do you generate such code in GCJ when you
compile a JVM dup?
No, of course not, but Java's stack is local to the function, and Java
stack operations can trivially be converted to a bunch of local
variables. A stack that is unbounded and shared between functions has
to be represented somehow.
Yes, but the common case is that the stack depth is statically known
and stack accesses can be trivially converted to pseudo-variables.
In the few cases where this does not hold, the front end has to
insert some stores/loads to the unbounded stack in memory; it's all
explained in <http://www.complang.tuwien.ac.at/projects/rafts.html>.
I already said
It is possible, of course, to do optimization in the Forth front
end, and this would allow you to generate trees that didn't touch
memory so much. This would help,
which is another way to say exactly the same thing. I was explaining
to John why the naive approach won't give top-quality results.
As long as you don't want to call other languages, there is no need
to use the usual calling conventions.
Well, I already answered that: I'm assuming we're not writing a new
back end.
I don't know gcc well enough to comment on the dependencies between
the back end and the calling convention;
The back end contains the code that handles the particular hardware
and the particular calling conventions. In the case where a processor
(such as the x86) has more than one calling convention, alternative
routines to generate entry and exit sequences are provided. This
logic has to be in the back-end, really, because it's generally
impossible to describe a calling convention without machine
dependencies. Some common parts of the logic are in the core
compiler, but there are such great differences between the various
calling conventions and hardware architectures that's not generally
possible.
but even if they are strong, it should be possible to treat calls
between Forth words as something lighter-weight than a
calling-convention call, no?
I guess this question amounts to "is it possible to stop the back-end
from generating ABI-compliant entry and exit sequences without
altering the back-end?", to which I suspect the answer is no.
There is a trick where you can call a subroutine within the context of
the current function by doing something like
tmp = &&bar;
goto foo;
bar:
...
foo:
...
goto tmp;
and this does indeed get you a super-lightweight call: no prologue,
epilogue, or local variables. However, if you were to do this very
much I think code quality would suffer because of the complex data
flow and the large number of temporaries.
Andrew.
.
- References:
- GCC front-end for FORTH?
- From: Enquirer
- Re: GCC front-end for FORTH?
- From: Andrew Haley
- Re: GCC front-end for FORTH?
- From: John Passaniti
- Re: GCC front-end for FORTH?
- From: Andrew Haley
- Re: GCC front-end for FORTH?
- From: Anton Ertl
- Re: GCC front-end for FORTH?
- From: Andrew Haley
- Re: GCC front-end for FORTH?
- From: Anton Ertl
- GCC front-end for FORTH?
- Prev by Date: Re: Forth and CP/M
- Next by Date: Re: Forth and CP/M
- Previous by thread: Re: GCC front-end for FORTH?
- Next by thread: Chinese version of Win32Forth
- Index(es):
Relevant Pages
|
