Oops! Forgot to fiddle the send address, yet again! :-(
Please see below ...
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Saturday, October 20, 2001 7:57 AM To: gpc@gnu.de Subject: Re: Errors and Standards (was: compiler bug)
J. David Bryan wrote:
On 19 Oct 2001, at 1:33, Frank Heckenbach wrote:
So, the following program would be allowed to output 0, according to
the
standard (because i might be mapped to an I/O address that happens to always yield 0)? I strongly doubt it?
Well, you've caught me without my copy of the standard at hand :-), but
as
I recall, there is a requirement that operations on integers must follow
the rules of integer math. I can't check whether assignment is one of those operations listed, but it seems reasonable. So, no, the program
you
cited wouldn't be a conforming program (pending confirmation from the standard).
I hope so.
But how could the compiler possibly enforce this? Binding to RAM vs. a mapped I/O port (or to ROM) would be done at link time, so must the compiler issue a warning for the "var" statement that variables must be bound to RAM? How else can we disallow such a program?
I think a "processor" according to the standard includes the compiler as well as the linker. Whether in practice a compiler alone
[Joe da Silva]
Yes, in the case of GPC, the "processor" must mean the compiler _and_ linker (it doesn't make sense to talk about just half a "processor" ;-).
On the topic of "binding" variables, my understanding is that any variables declared in the "var" block of a program are local to the program and exist only during the execution of the program, unless they are included in the program's parameter list - just like file variables!
Suppose there is an implementation-dependent system variable called "user", that contains a string (with the user's name). Now, if the "processor" has a predefined binding for this variable, a program could reference it, _without_ defining it in the "var" block. However, if "user" were defined in the program's "var" block, then this would be a _local_ variable called "user", not the predefined system variable (assuming of course it isn't also included in the program's parameter list)!
So, in your previous example, where you defined a variable called "i" and assigned it the value 42, this variable could not have any other binding - it is simply a normal variable and must behave as such!
(such as GPC) that might be used in conjunction with various linkers could be 100% conforming, is another question (and the answer is probably no, without making some requirements on the linker and forbidding the user of linker scripts etc.).
Yes, but some things (like that the program above should write 42, possibly preceded by a number of spaces) are guaranteed, I think.
Unfortunately, what you and I think has no bearing on the matter. Only what the standard "thinks" is important! ;-) Cite a passage from the standard that states that main program block-level variables may not be bound to external entities, and I will concede your point happily.
I'm just packing my bags and will be gone for the weekend, but I'll look when I'm back ...
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
On 22 Oct 2001, at 15:43, da Silva, Joe wrote:
On the topic of "binding" variables, my understanding is...
It is not my intent to argue simply for the sake of arguing. Honestly! But if we're going to decide Pascal issues on the basis of understandings and beliefs, then why have standards?
I have found over time that many of my understandings as to how things work turn out to be wrong when I examine the systems in detail. Here, fortunately, we do not have to decide how Pascal works by trial and error. We have a standard that says explicitly how things are supposed to work.
I plead that we cannot make GPC standards-compliant if we base its operation on our belief and assumptions. Instead, we must structure GPC's operation strictly according to the semantics outlined in the relevant standards -- at least, we do if we want to claim compliance.
...this variable could not have any other binding - it is simply a normal variable and must behave as such!
Can you support the "must" with a citation from the standard?
I work with embedded systems, i.e., microprocessor-based controller cards. I develop these "bare board" controllers using Pascal, specifically, on an HP development system. On that system, the Pascal compiler separates the program code and static data (i.e., main block-level data). It does this so that the code may be burned into ROM.
The particular processor that I target, the Motorola M68K family, has no I/O instructions. All I/O is memory-mapped, i.e., I/O is performed by normal reads and writes to address locations that are mapped to specific hardware registers instead of RAM. Because there is no controlling operating system on these boards, there is no implementation of program parameters (because there is nothing "outside" of the program).
So in this application, I/O devices are represented in the Pascal programs as main block-level variables. A serial port configuration register might be mapped to an "integer" variable, for example. The actual mapping of variables to devices is done by the linker, which allows the specification of the addresses at which the variables are to be assigned.
So the programs that control these boards have no program parameters and no "read" or "write" calls; they control the machines in which they are embedded through the mechanism of variable mapping. These programs cannot be classified as "pointless."
But are they legal Pascal? That is, do they conform to the syntax and semantics of the standard?
They conform to the syntax, surely (e.g., GPC compiles them without complaint). As far as I can determine, they conform to the semantics as well, i.e., they obey all of the rules in the standard. The standard requires certain semantics for, e.g., integer variables (scope rules followed, arithmetic behaves as expected, etc.), and all of those rules are followed by the hardware as well. I do not see anything in the standard that precludes the implementation of variables in hardware devices, rather than in RAM, as long as the semantics listed in the standard are obeyed.
As I've noted, I would be pleased if someone could cite a section of the standard that says that a Pascal program constructed as above is illegal. My "understanding" is that my program is legal, but with such a citation, I would withdraw that assertion. But I regret that simply saying that such a program seems to be illegal, or isn't normal, or ought to be prohibited, just isn't good enough if the goal here is to make GPC conform strictly with the ISO standards.
And that's the only point I'm trying to make: whether you or Frank or I believe that a given program is "pointless" isn't the issue. The only issue is whether the standard prohibits it, and the standard itself is the only authority on that matter. Any discussion of what GPC must or must not do has to be supported by the standard.
-- Dave
-
da Silva, Joe -
J. David Bryan