Re: Modified version of the Gray parser generator
- From: anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
- Date: Sat, 24 May 2008 13:47:04 GMT
Gerry <gerry@xxxxxxxxxxxxxxxxxxxxxxx> writes:
On 24 May, 09:16, an...@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl) wrote:[size comparison between the versions]
- I re-organised it by moving the generate code into separate
classes in another file for convenience when switching between the
two systems
Good. These two classes would then be the code to compare.
The other changes also sound interesting.
Anyway why is the size important for an off-line tool when it uses so
little of a modern desktop's resources?
It is an indication of the development effort.
I have now made the direct-call change in the original Gray (I guess
it uses the direct call in the same cases as your version does). On a
64-bit Gforth this change costs 72 bytes in Gray itself. It amortizes
itself pretty quickly, leading to overall savings of 280 bytes for
prims2x.fs.
OK I have clearly been using an older version,
Sorry if I was unclear. I just made the change today, to determine
the cost and benefits, and have not released or commited it anywhere.
I got it from gray5.zip
from your web-site. Is the newer version available, the version in the
Gforth CVS repository seems to be older than gray5
Gray5 is the latest released version, the version in Gforth is a
branch from Gray4. I made the experiment with the Gforth version for
convenience.
The original Gray calls the actions directly. I expect a competent
inlining Forth system to do the inlining by itself, but of course your
approach also does that on systems that don't inline (or are not very
competent at it).
I don't understand, as far as I can see actions are compiled in a
:noname definition
Yes.
and called via an EXECUTE.
No:
: generate-action \ syntax-expr -- )
action compile, ;
That compiles a direct call to the action, no EXECUTE involved in that
call.
Are you saying that a
competent Forth system can work out what to in-line just from
knowledge of the xt (I'm just asking - I don't know).
Yes. It also knows what to EXECUTE from the xt, so all the
information is there.
Wouldn't auto
in-lining depend on the size of the code to be in-lined?
It depends. If there is only one call to the definition, as is the
case for actions, size does not matter (that's simplified, several
papers about inlining strategies have been published).
OTOH, your approach has the usual problems of source inlining and
source-code macros: The context (in particular: BASE, the search
order, and the whole dictionary) can be different from the location
where that code appeared in the source code. In your case that
problem is mitigated by making the generated code explicit as a
separate file.
Of course the context is going to be different as the standalone
parser will be compiled without Gray present and the user has to be
aware of that. But you're implying that it will be different within
the parser source code itself which makes me wonder if we're talking
at cross purposes. For example given the Gray source code for a rule:
nonterminal xyz
(( 'A' {{ this that and the other }} 'B' )) xyz rule
I would generate code such as
: xyz 14 testtoken this that and the other 19 testtoken ;
where 14 and 15 refer to token values for terminals 'A' and 'B'
(another slight improvement).
Why would the internal context be different? The only reason I can
think of is that Gray compiles the action when the source code is read
and generates the code for the rule in a later pass so I suppose the
context could be changed in the meantime.
Yes, that's it. As a simple example, consider BASE:
hex
(( A {{ 10 }} B )) <- C
decimal C parser foo
Here the 10 is interpreted as a hex number. If your generated parser
is compiled with BASE set to decimal, the result will be wrong.
However, the source inlining usage also has an advantage: you can use
locals and the return stack to communicate between different actions
in the same rule.
BTW, I advise against using names like 'A', because these names might
be misinterpreted as literal characters
<http://www.forth200x.org/number-prefixes.html>, and they shadow some
number prefixes, possibly leading to mistakes.
- 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 2008: http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
.
- Follow-Ups:
- References:
- Modified version of the Gray parser generator
- From: Gerry
- Re: Modified version of the Gray parser generator
- From: Anton Ertl
- Re: Modified version of the Gray parser generator
- From: Gerry
- Re: Modified version of the Gray parser generator
- From: Anton Ertl
- Re: Modified version of the Gray parser generator
- From: Gerry
- Modified version of the Gray parser generator
- Prev by Date: Re: Modified version of the Gray parser generator
- Next by Date: EuroForth 2008 registration open, and other information
- Previous by thread: Re: Modified version of the Gray parser generator
- Next by thread: Re: Modified version of the Gray parser generator
- Index(es):
Relevant Pages
|
Loading
