rkl@mva.cs.liv.ac.uk (10/03/89)
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). 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. 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$). 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. 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. 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... } 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). 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. 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 ! 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... 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. 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. 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. ****************************************************
mjs@hpfcso.HP.COM (Marc Sabatella) (10/05/89)
> - 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). As you seem to realize, this is not so much a Pascal defect as a lack of user disk quotas. >2. Otherwise clause in a Case statement is compulsory at run-time Standard Pascal does not even have an otherwise clause; it is indeed an error if you don't cover each case individually. > 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... The 800 pascal compiler shares the same code generator as C and Fortran, and hence can use the same optimizer. The 300 compiler compiles one-pass-direct-to object file, and doesn't even share the assembler. >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. True. We are investigating merger strategies (there is also Apollo Pascal to consider now!), but don't hold your breath :-( -------------- Marc Sabatella HP Colorado Language Lab marc%hpfcrt@hplabs.hp.com
steve-t@hpfcso.HP.COM (Steve Taylor) (10/05/89)
/ comp.sys.hp / rkl@mva.cs.liv.ac.uk / writes: } The rest of these points are a wishlist for HP Pascal: } 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). You might try using structured constants: PROGRAM test (OUTPUT); TYPE fred_row = ARRAY [ 1..2 ] OF INTEGER; fred_type = ARRAY [ 1..2 ] OF fred_row; CONST fred_first = fred_type [ fred_row [ 17, 6 ], fred_row [ 13, -2 ] ]; VAR fred : fred_type; BEGIN fred := fred_first; writeln ( fred[1,1], fred[1,2], fred[2,1], fred[2,2] ); END. When I run this (on a Pascal Workstation), I get: 17 6 13 -2 Regards, Steve Taylor NOT A STATEMENT, OFFICIAL OR OTHERWISE, OF THE HEWLETT-PACKARD COMPANY. PS. My first attempt at a response got away unedited. I deleted it, but it may have been sent before I could catch it. If so, my apologies.
decot@hpisod2.HP.COM (Dave Decot) (10/06/89)
> 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). If you think that's fast, try (don't really): prealloc foo 1000000000 Dave
shankar@hpclscu.HP.COM (Shankar Unni) (10/06/89)
> 1. Extremely large executable size (On Series 800 machines only) > ------------------------------- Well, this is sort of a misfeature, especially considering that Pascal does not guarantee initialization at load time.. This has been reported more than once, but I'm not sure if a fix is forthcoming in the *near* future, since it's so easy to work around (after all, how many of these arrays do you have? You could easily "new" this arrays on the heap). > 2. Otherwise clause in a Case statement is compulsory at run-time > -------------------------------------------------------------- All for the sake of the "Pascal" spirit. We try to catch as many exceptions as possible, and according to the Pascal standard, this is an error, and quality implementations must catch it. I therefore don't consider this a bug, but consider the other compilers buggy in not catching this. > 5. The + operator for strings is fussy about its operands > ------------------------------------------------------ I agree. It could be a little more flexible. > The rest of these points are a wishlist for HP Pascal: > 1. Array slicing > ------------- > var fred : array [ 1..7 , 1..7 ] of integer ; > begin fred [ 1 , ] := fred [ 2 , ] end ; { OK, so it's uninitialised... } Actually, the syntax for that is fred[1] := fred[2]; I.e., if fred is a 2-d array, fred[1] is a one-d array, and fred[1,1] is an element. > 2. Constant assignment to arrays (and other types ?) in the var section > -------------------------------------------------------------------- > var fred : array [ 1..2 , 1..2 ] of integer := > ( ( 17 , 6 ) , ( 13 , -2 ) ) ; There is an ugly way of doing this (at least in the 800 pascal): Name each subtype of fred explicitly: 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. There is still no way to initialize at compile-time, but this is better than nothing.. > 3. Access to external ints in C library routines > --------------------------------------------- This is one of the sore points. Both Pascal's provide ways to do this, but they both rely on tricks of the implementation, and they are incompatible with each other, so I won't waste your time telling you about them. > 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 Gee, how did you guess? :-) Seriously, though, there are strenuous efforts under way to converge them to a common base. Your suggestions are valuable for this exercise. If you have any sort of an HP support contract, please also report any problems you find to your HP support rep, so that *you* can be sure that they are officially logged and recognized. I'll forward these comments to the Pascal team in any case. P.S.: there is an ANSI committee currently working (in the late stages) on a standard for "Extended Pascal", which will give you most of what you wished for above. The committee is X3J9. See if you can get a copy of the draft from somewhere. Let your HP rep know if you're interested. ----- Shankar Unni ("ex-Pascal grunt") E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar
dhandly@hpcllz2.HP.COM (Dennis Handly) (10/06/89)
> 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 ; > ... The above problem used to create an object file (.o) of the same large size. This was solved with a partial roll to the object file format that caused all compilers and the linker to be changed. Another roll had an explicit design for these large uninitialized areas. On MPE XL, an attempt was made to change the executable, NMPRG, size in the linker, but certain areas were not initialized properly, and the enhancement was backed out. (COBOL is more complex than Pascal since its items can be initialized or not, which creates gaps.) This problem currently affects only Pascal, COBOLII/XL and RPG/XL. Other languages don't use the $GLOBAL$ subspace. A simple work-around, other than NEW, is documented in the COBOLII/XL manual: Use the EXTERNAL clause. (This puts the item in $BSS$.) A similar work-around for Pascal would be to put the item in a module or to compile with the $GLOBAL$ option (all or nothing). The later method may cause extra code to be generated to load/store items.