Michel Olagnon wrote:
> "no restriction" either means
> 1) a system dependent limit, or
> 2) that any standard system needs to be able to handle unlimited values.
> The first case means that you loose a lot of portability.
If the standard were to specify that there's no limit on, say, statement
size, this should be explicitly prohibited, for the stated reason.
> The second means that most of the efforts of the compilers and tools writers
> will have to be devoted to finding tricks to handle these uncommon usages.
Many of these "insurmountable" problems actually have simple solutions that
have negligible impact on performance (compile speed) and are, say, 0.1%
as difficult as things compilers routinely do (e.g. generic resolution).
Consider the statement length problem (for simplicity of discussion, in
the case that line length is still limited -- but this isn't an order-of-
magnitude simplification).
One starts with
TYPE BUFT
TYPE(BUFT), POINTER :: NEXT
CHARACTER(LEN=132) LINES(40)
END TYPE BUFT
TYPE(BUFT), TARGET :: BUF
TYPE(BUFT), POINTER :: CUR_BUF, LAST_BUF
CUR_BUF => BUF
LAST_BUF => BUF
NULLIFY(LAST_BUF%NEXT)
Then, do what's done now, _until_the_number_of_lines_exceeds_40_!
When (and only when!) the number of lines exceeds 40, instead of emitting
a "statement too long" error message,
ALLOCATE(LAST_BUF%NEXT)
LAST_BUF => LAST_BUF%NEXT
NULLIFY(LAST_BUF%NEXT)
If the lexer/parser haven't figured out the statement type early on, and
need to back up, re-start the analysis at BUF, continue _exactly_ as one
would with a fixed limit _unless_ there's a non-null %NEXT. In that case,
instead of LINE = LINE + 1, you have CUR_BUF => CUR_BUF%NEXT; LINE = 1.
When the statement's done, either de-allocate all but the first chunk,
or just keep all the chunks around on the theory that one long statement
implies a programmer's propensity to use them again -- compiler writer's
choice.
(This is called a "linked list." It's taught no later than first term
of third year of university curricula.)
In the case that there isn't enough memory to keep on allocating
(that is, ALLOCATE returns a non-zero STAT value), the statement
could be stored on a scratch file, _but_only_in_that_case_. Once
again, this adds negligible cost in the case when it's not used.
This appears to add at most a few tenths of a percent to the cost,
complexity and running time of a program that lexes/parser Fortran,
and appears to add almost nothing to the running time in the case
when statements are short.
I can't imagine that the clever folks who bring us our compilers are
too dense to figure this out, too.
Is there _really_ more than that, or is the resistance just inertia?
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|