chip@hpclisp.HP.COM (Chip Chapin) (10/14/89)
*** Warning: Long Response Ahead *** This message is a semi-formal response to the HP Pascal issues raised by Richard Lloyd of the Liverpool University Computer Science Department in his note entitled "HP9000 Pascal Buglist/Wishlist", posted on comp.sys.hp October 3, 1989. I say "semi-formal" because, while I am the HP-PA Pascal project manager (s800 and s900), and while both s300 and s800 project teams have been involved in preparing the response, it is important to stress that, though we may (or may not) appear knowledgeable, nothing in this note should be construed as a commitment by the Hewlett Packard Company itself to any future product enhancements. These are our *individual* opinions about what ought or ought not to be done. When I first saw Mr. Lloyd's comments, I got the silly idea that a coordinated [but still unofficial :-)] response from the s300 and s800 compiler groups would be useful. Of course, the problem with that plan is the time required to collect input from several people and munge it into a single response. As a result, this posting is a full week later than it would have been if I had just let nature take its course. Oh well, I'll know better next time. Fortunately, in the meantime several knowledgeable individuals have responded to many of Richard's concerns. Besides my own remarks, most of the comments interspersed with the original posting below are from Jim Bigelow of the s300 Pascal project in Ft. Collins. Thanks, Jim! Several other people on the s800 Pascal in Cupertino also contributed. I'm afraid the whole thing is rather long, but hopefully it will serve as both a satisfactory response and a useful basis for further discussion. Jim makes the following observation, with which I wholeheartedly agree... I find myself responding in one of two modes, defensively which causes much recourse to exact definitions, or as a sympathetic user where I agree with his wished for behavior. "You can please some of the people some of the time, and most of the people, most of the time,but you can't please all the people, all the time." [1] As the sympathetic user I could wish that the Pascal language were more than it is. As the hard-nosed implementor, however, I need to maintain precise accordance with published standards, and avoid the "Swiss Army Knife" approach to compiler implementation. -- Chip Chapin -------------------------------------------------------------------- Chip Chapin, Hewlett Packard Company, California Language Lab (HP/CBO/NSS/CSG/DLD/LMO/CLL) uucp: ... {allegra,decvax,ihnp4,ucbvax} !hplabs!hpda!chip or ... uunet!hp-sde!hpda!chip Internet: chip%hpda@hplabs.hp.com or chip%hpda@hp-sde.hp.com HPDesk: chip (hpda) /HPUNIX/UX USMail: MS47LZ; 19420 Homestead Ave; Cupertino, CA 95014; USA Phone: 408/447-5735 Fax: 408/973-8455 HPTelnet: 1-447-5735 -------------------------------------------------------------------- > Richard K. Lloyd writes: > We are currently running HP-UX 3.1 on an HP9000/850 and HP-UX 6.2 on various > HP9000 Series 300 workstations. Since there has just been a very interesting > posting on HP-UX 3.1 problems, I thought I'd weigh in with a similar document > about HP Pascal. > > Firstly, here's a list of currently strange 'features' (bugs to you and me) : > > 1. Extremely large executable size (On Series 800 machines only) > ------------------------------- > > Try compiling the following HP Pascal program on a Series 800 machine... > (WARNING: Make sure you have at LEAST 250 MBs of free disk space !) > > program bigexec ( input , output ) ; > > type str255 = string [ 255 ] ; > > var huge : array [ 1..1000 , 1..1000 ] of str255 ; > > begin > writeln ( 'If you get this far, then you have plenty of disk space !' ) > end. > > Although this would normally be dismissed as a downright inefficient way of > building an s800 executable (what's wrong with a malloc at run-time ?), this > really does highlight the lack of disk quotaing (HP-UX 7.0 should cure this) > - any normal user can fill the disk in less than one minute. Compiling the > same program on Series 300 machines results in a less dramatic executable > size (69K). Several people have already responded to this issue (Shankar Unni, Dennis Handly, Marc Sabatella and Dave Decot (sort of :-)), and I really have nothing to add. We'd like to see this change. > 2. Otherwise clause in a Case statement is compulsory at run-time > -------------------------------------------------------------- > > If the case statement falls through all the selector values without > matching ANY of them at run-time, then the otherwise clause MUST be > present. I'm sure most Pascals just fall out of the case statement > without an error. The worst thing about this is that it is not > reported at compile-time - leading to programs that could be > potentially crashable when they really shouldn't be. Here is good example of programming practice vs. language standards. UCSD Pascal [incorrectly] allowed the program to fall through the case statement, and some Pascals still follow that policy. I may be wrong, but I think even the Zurich P2 and P4 compilers would fall through. In the days before the "otherwise" extension (or UCSD's CASE .. ELSE) was made to the original J&W Pascal, this behavior made some sense, even though it was "incorrect". With the ability to use "otherwise", however, in my humble opinion there really is no justification for this sloppy practice. John Flores (jjf@hpcllz2.hp.com) comments: The behaviour of our CASE statement is consistent with the ISO/ANSI standard. The process should not just drop through the Case statement if the case-index does not match any of the constants: From the ISO standard: One of the case-constants shall be equal to the value of the case-index upon entry to the case-statement, otherwise it shall be an error. This is impossible to detect at compile time unless the case-index was a constant and in that case you wouldn't need a case statement. And Jim Bigelow writes: As Marc Sabatella points out, ansi pascal does not allow for an otherwise clause. Wirth says in "pascal, User manual and report", 2nd Edition, 1978, P31. "The case statement selects for execution that statement whose label is equal to the current value of the selector; if no such label is listed, the effect is undefined." As Mr Lloyd points out, in real practice, some provision must be supplied to account for the lack of an otherwise. S300 pascal will report, at run time, if the case selector assumes a value for which there is no label. program other(output); var i :integer; begin for i := 0 to 10 do begin case i of 0: writeln('0 case OK'); end; writeln('statement after case'); end; end. {Program other.p} When the above is compiled and run the following run-time messages are seen: $ pc other.p $ a.out 0 case OK statement after case ERROR -9 IN LINE 0. Case value range error. Both the 68K and HP-PA Pascal compilers provide the keyword "otherwise". When the above program is modified to use otherwise, it becomes: program other(output); var i :integer; begin for i := 0 to 10 do begin case i of 0: writeln('0 case OK'); otherwise writeln('Hit otherwise clause'); end; writeln('statement after case'); end; end. {Program other.p} This program compiles and runs successfully, and safely. > 3. 'Accessed, but not initialised' compile-time warning > ---------------------------------------------------- > > This appears on the Series 800 Pascal if you attempt to access a > variable before it has been initialised. I'd like to see this warning > on the Series 300 Pascal too - it's quite handy (and can be switched > off if it annoys you with $WARN OFF$). It was added to the s800 Pascal as an easy by-product of the optimizer's machinations. We agree that it would be a useful enhancement for the s300 Pascal, and Jim has said he would "add it to the list of waiting enhancements". If it's not easy to do, however, I would personally not hold my breath. > 4. close ( filevar ) doesn't have a sensible default behaviour (Series 300) > ----------------------------------------------------------- > > When a file is opened for output with the rewrite statement, using the > close statement with only the file variable as a parameter not only closes > the file BUT DELETES IT. This is exactly the opposite behaviour of all other > Pascals I have come across. Yes, you can specify close ( filevar , 'SAVE' ), > but you shouldn't have to. As you have noted, only the s300 compiler exhibits this behavior. Even so, Richard should recognize that this is time-honored Pascal trait, and not something that was just dreamed up in Ft. Collins. For example, I quote from the UCSD Pascal Users Manual, Version IV.0 (1981): "if [close( ..., ] OPTION is not present, the CLOSE simply sets the file state to closed. If the file was opened using REWRITE and is a disk file, it is deleted from the directory". If my memory serves me correctly, the file would be deleted even if existed prior to the program run. This even more extreme than the s300 Pascal behavior, which deletes the file only if it was newly created by the program. Jim B. adds that "The 300 manual says that close accepts: 'SAVE' -- save file and make permanent 'NORMAL' or 'TEMP', or none --If the file is already permanent, it remains in the directory. If the file is temporary, it is removed. The behavior can be viewed as good, because it cleans up it own temp files, rather than cluttering up the file system. On the otherhand, existing files remain in place. However, it's a gotcha for porting." I think we're undecided about which behavior is "best". If anything, I personally lean toward the s300 style for the reasons Jim has given. But I hear one customer voting for the s800 style. Any others? I *would* like to see the compilers be consistent on this point. > 5. The + operator for strings is fussy about its operands > ------------------------------------------------------ > > Quiz time ! Which of the following is legal in HP Pascal (fred is a string) ? > > a) fred := fred + '*' ; > b) fred := fred + chr ( 42 ) ; > c) bill := '*' ; fred := fred + bill ; { bill is a char } > > Answer: > > a) and b) both work on Series 300 machines. > Only a) works on Series 800 machines. > c) works on neither ! > > This is incredibly inconsistent behaviour - my opinion is that all three > should be perfectly legal. This is one of those things where we're torn between ease of use on the one hand, and language rigor on the other. Can you say "Strong typing"? I knew you could! I'm afraid we don't have any plans to make all of these legal, as Richard asks, and maybe the s300 will make (b) illegal (as I guess it really should be). On the other hand, as programmers most of us would prefer all of them to be allowed. Can anybody list several popular Pascals that *do* allow all these constructs? If it became an issue for porting non-HP Pascal code, we'd have an easier time rationalizing a change. Jim Bigelow explains why it works the way it does... In keeping with the strict type checking of pascal, note that the concatenation operator is only defined for strings. > a) fred := fred + '*' ; This works because string literals, '*' in this case, are "interpret[ed] as type PAC, string, or char depending on context" [2] > b) fred := fred + chr ( 42 ) ; Since char ( 42 ) is a char and not a string, this looks like a bug, or a bug that is a feature :-) [in the s300 Pascal]. > c) bill := '*' ; fred := fred + bill ; { bill is a char } Opps, can't fool the compiler here, bill is a char and not a string so type matching says this won't work. And we get: Operand(s) are not proper type for this operation; > The rest of these points are a wishlist for HP Pascal: > > 1. Array slicing > ------------- > > I really miss the ability to do: > > var fred : array [ 1..7 , 1..7 ] of integer ; > begin fred [ 1 , ] := fred [ 2 , ] end ; { OK, so it's uninitialised... } As Shankar Unni pointed out in his response, fred[1] := fred[2]; works fine on both compilers. Why would you want to do it the other way?? > 2. Constant assignment to arrays (and other types ?) in the var section > -------------------------------------------------------------------- > > Again, I miss this lovely construct: > > var fred : array [ 1..2 , 1..2 ] of integer := > ( ( 17 , 6 ) , ( 13 , -2 ) ) ; > > It saves having to put the data in a text file (or 100's of assignments). Aside from using C-style comments in his example ("/*" instead of "(*"), Shankar's example of using structured constants works fine in both s300 and s800 Pascals: program p (input, output); type oneDarray = array[1..2] of integer; twoDarray = array[1..2] of oneDarray; var fred : twoDarray; const fred_init = twoDarray [ oneDarray [17, 6], oneDarray [13, -2] ]; begin fred := fred_init; (* initialize at one shot *) end. Steve Taylor posted a similar example. I agree with Shankar's remarks that this seems ugly compared to the way you have illustrated. And, obviously, this does not take any advantage of the ability to have pre-initialized static data in your executable file. Once again, we're running squarely into "Pascal purity" issues. And, again, I would say that "if enough customers wanted it..." we could be flexible here. I've got Richard's vote. Any others? > 3. Access to external ints in C library routines > --------------------------------------------- > > Whilst attempting to call curses routines from Pascal (yes, Frank, I noticed > the flaky curses routines too !), I had to resort to C 'glue' routines to > get at external ints inside the curses library, even though HP Pascal *can* > call external functions and procedures. In Shankar Unni's response, he painted a rather bleak picture here, stating that the s300 and s800 had incompatible implementations. However, as he now admits, he was thinking of the "bad old days". The current situation is getting pretty reasonable. The following example from Jim Bigelow works for both compilers. He does, however, point out a significant remaining bug (even in 7.0) in the s300 Pascal, that would still cause problems for Richard's application. This can be done by aliasing the variable to its C library name, e.g., { Title: errno.p -- access errno in libc Last Mod: Thu Oct 5 15:50:15 1989 Author: Jim Bigelow <jimb@hpjb> } program errno (input,output); var unix_error_number $alias '_errno'$ :integer; begin writeln(unix_error_number); end. {Program errno} However, these is a bug in the 300 compiler, I will be fixing this month where the compiler lower-case's the alias. This makes it hard to access LINES and COLS from the curses library. Opps :-) > 4. Executable size seems rather large (300 or 800 Series) > ------------------------------------------------------ > > Now I know that there aren't shared libraries in HP-UX 3.1, but even so, a > size of 60 to 70 K (300 Series) or 150 K upwards (800 Series) for the most > trivial of programs seems a bit on the gargantuan side. And people complain > about the size of C executables ! For the s800, while I admit that a problem exists here, I wonder if you've tried running strip(1) on your executables? For example,the "errno" program above produced an a.out of 133KB on my 840 with a recent compiler. When I stripped it ("strip a.out"), it was reduced to less than 84KB. Still large, but much less embarrassing. Jim B. says (re the s300): With 6.5, file buffers were increased to 8K buffers to match the Kernel buffer increase. I consider the arrival of shared libraries in the 7.0 release on both systems to be the rest of the solution to this particular problem. > 5. Series 300 optimisation > ----------------------- > > Call me stupid if you want, but I can't understand why pc on the Series 800 > has a -O option (optimisation), but the Series 300 pc does not... Marc Sabatella has already pointed out that the s300 compiler does not have a separate optimizer. Jim adds: On the positive side, there is no -O because all the optimizations the 300 provides, is done already. The negative side is that's not much: limited common subexpression folding, constant folding, register allocation for with and intermediate bases. Resources are few for optimizations, but the spirit is willing. :-) > Conclusion > - ---------- > > As I think has already been mentioned, it is clear that Series 300 and Series > 800 Pascal are written by different people within HP. This does lead to > differences in HP Pascal behaviour that, whilst not difficult to work around, > are just a little bit too niggly to go away that easily. We agree, and thank you for pointing out some differences that became an issue for you. Actually, I'd like to see much more from you and other users along these lines. The two Pascals have come *much* closer together in the last two years, and we'd like to see which of the remaining differences are most important. But, for now, as I look back over the issues you have raised, really only two (close(f) behavior and fussy + operator for strings) describe syntactic or semantic differences between the two Pascals. Were those really the worst ones you encountered? > Although I have made some negative points about HP Pascal, I am actually > reasonably impressed, syntax-wise, with it and would be delighted if some of > the suggestions/bugs were implemented/fixed in some future release. We're very glad you are finding it useful. In summary, we hope to address your bug-1, bug-3, and bug-5 in some fashion in the future (but this cannot be promised, please understand. Refer to disclaimer at top of this note). On bug-2, we consider ourselves "correct" as-is. I don't know what to do about bug-4, and I remain open to suggestions. I believe we have already addressed your wishlist items 1, 3, and 4, and functionally addressed item 2, though not as well as you would like. Personally, I think a complete solution to compile-time initialization is not worth the effort, given that we already have structured constants, but if the demand is sufficient, well, maybe. Finally, wishlist item 5 we hope to address in the future, same caveat as above. > Richard K. Lloyd, **** This is a MicroVAX II running VAX/VMS V5.1 **** > Computer Science Dept., * JANET : RKL@UK.AC.LIV.CS.MVA or * > Liverpool University, * RKL@000010500211.FTP.MAIL * > Merseyside, England, * Internet : RKL%mva.cs.liv.ac.uk@cunyvm.cuny.edu * > Great Britain. **************************************************** References: [thanks, Jim] [1] A. Lincoln [2] "HP Pascal Language Reference, HP 9000 Series 200/300 Computers", Edition 3, for HP-UX 6.5, Section Strings, Page 216.
mjs@hpfcso.HP.COM (Marc Sabatella) (10/16/89)
>For the s800, while I admit that a problem exists here, I wonder if >you've tried running strip(1) on your executables? For example,the >"errno" program above produced an a.out of 133KB on my 840 with a >recent compiler. When I stripped it ("strip a.out"), it was reduced >to less than 84KB. Still large, but much less embarrassing. > >Jim B. says (re the s300): > With 6.5, file buffers were increased to 8K buffers to match the Kernel > buffer increase. > >I consider the arrival of shared libraries in the 7.0 release on both >systems to be the rest of the solution to this particular problem. Woah - no shared libraries in 7.0; you'll have to wait until next summer for 8.0 or whatever they have decided to call the release. Also, shared library support for Pascal on the 300 is not currently planned for that release, although it is on the 800. There are several things that could be done to improve things even given archive libraries. In particular, my pet peeve is that the library is so poorly structured, a simple "hello world" program results in the "arctangent" routine being brought in from libpc! -------------- Marc Sabatella HP Colorado Language Lab (CoLL) marc@hpmonk
chip@hpclisp.HP.COM (Chip Chapin) (10/17/89)
There are two amendments I'd like to make to the original posting: >/ chip@hpclisp.HP.COM (Chip Chapin) / 7:42 pm Oct 13, 1989 / > However, these is a bug in the 300 compiler, I [Jim B.] will be fixing this > month where the compiler lower-case's the alias. This makes it hard > to access LINES and COLS from the curses library. Opps :-) I should have pointed out that $alias on the s800 has the *same* property. In fact, the case-insensitivity is a bona-fide "feature" rather than a bug. Clearly, however, a user also needs a way to make the external name case-sensitive, and that is why, on the s800, the default behavior may be overridden using the $LITERAL_ALIAS option. The "bug fix" that Jim refers to for the s300 is not to change the behavior of $alias, but to add the $literal_alias option, a la the s800. And with respect to large executables I said: >I consider the arrival of shared libraries in the 7.0 release on both >systems to be the rest of the solution to this particular problem. I must have been asleep when I wrote that. Shared libraries are most emphatically *NOT* in the 7.0 HP-UX release. "They may be in a future release" :-) :-) Chip