[comp.sys.hp] HP9000 Pascal Buglist / Wishlist

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.