<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=iso-8859-15">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi fpc developers,<br>
</p>
<p>here enclosed a patch to the compiler (and ppudump) to support
the BASED construct (PL/1 and PL/M style), together with a patch
to Lazarus codetools in order to be able to use it with Lazarus
IDE.<br>
</p>
<p>For those unfamiliar with the BASED construct, here's a short
description taken from Intel's PL/M-86 manual:</p>
<i><b>Based Variables</b><br>
Sometimes a direct reference to a PL/M-86 data element is either
impossible or inconvenient. This happens for example, when the
location of a data element must remain unknown until it is
computed ad run time. In such cases, it may be necessary to write
PL/M-86 code to manipulate the locations of data elements
themselves.</i><i><br>
</i><i>To permit this type of manipulation PL/M-86 uses "based
variables". A based variable is one that is pointed to by another
variable called its "base". This means the base contains the
address of the desired (based) variable.<br>
<br>
</i>In short the BASED construct makes the C-style dereferencing
operator unnecessary, by moving dereferencing from code to
declaration.<br>
<br>
In fpc this translates into code looking like this, in this trivial
example:<br>
<br>
<pre>var
I: BYTE;
I1: INTEGER;
ItemPtr: Pointer;
Item: BYTE BASED ItemPtr;
IntegerItem: INTEGER BASED ItemPtr;
....
ItemPtr := @I;
Item := $41;
....
ItemPtr := @I1;
IntegerItem := -32767;
</pre>
This code will load the BYTE value $41 into the variable I, and the
INTEGER value -32767 into the variable I1.<br>
<br>
<br>
In more formal terms, the Declaration section of the fpc manual
should include a new path:<br>
<br>
<pre>>--Variable modifiers ---------- based ---------- pointer -------------->
| | | | |
| -- PUint expression --- | |
etc..
</pre>
<pre>
</pre>
<p>The main points are:</p>
<ul>
<li>
<p>It doesn't break anything. - I have thoroughly tested it in
my private fpc versions since fpc 2.2.4</p>
</li>
<li>
<p>Nobody is forced to use it: whoever doesn't like it can
simply ignore its existence.</p>
</li>
<li>
<p>It provides a feature consistent with the general Pascal
approach, to avoid whenever possible redundant dereferencing
and typecasting, moving the tedious jobs from the developer
to the compiler.</p>
</li>
<li>
<p>It saves a number of C-style declarations, dereferencing and
typecasting, and it provides a better type checking, making
the code less error prone and much more readable and more
"Pascalish".</p>
</li>
<li>
<p>It's very useful in message passing techniques, where
different message types are funnelled to a single endpoint.
Typically such messages are records composed by a fixed header
which tells about the message type, followed by a variable
content. They can be found everywhere, from IPC to X11
interface to tcp/ip packets.<br>
</p>
</li>
<li>I found it also useful in data entry applications, where
different fields require different data types.</li>
</ul>
The implementation is rather trivial: a BASED declaration is nothing
else than an ABSOLUTE declaration with an added dereferencing.
Therefore I've simply duplicated the code for the ABSOLUTE, with a
minimal change in pexpr.pas, and minimal adaptations elsewhere.<br>
<p> </p>
<p>The enclosed patches are provided just to permit testing,
evaluation and scrutiny from fpc maintainers. They only contain
what is required for my personal usage.</p>
<p> If the idea is not rejected, then a number of refinements (which
I'm ready to implement) are required to make the feature generally
available:</p>
<p>- All architectures should be supported (now it's only for x86_64
- symcpu.pas).<br>
</p>
<p>- It should be decided if to make the feature generally
available, or conditioned by an {$IFDEF FPCHASBASED}<br>
</p>
<p>- It should be decided if the feature should be available in all
modes or only in a selected number of modes (what of TurboPascal
Mode or Delphi Mode?).</p>
<p>- It should be decided if error messages should be specific for
the BASED construct or common to the ABSOLUTE one, slightly
rephrasing the error message.</p>
<p>- It should be decided if internal error # which currently keep
the same number of the nearby ABSOLUTE internal error should be
given new values.</p>
<p>- Maybe something else which I failed to notice.</p>
<p>I'd love to see my favourite programming language enriched by
such a feature!</p>
<p>Giuliano<br>
</p>
<p><br>
</p>
</body>
</html>