jwb@LINDENTHAL.CAE.RI.CMU.EDU (John Baugh) (05/04/89)
[I recently posted a similar request to comp.lang.pascal with little response] Can anyone give me some information on Apollo's Pascal compiler? I plan on using it for a course in the Fall. Does it have a corresponding interpreter? Profiling capabilities? Other tools and/or utilities? Is it bsd-like? ISO compliant (apparently, it isn't Level 1 compliant, e.g., conformant arrays)? It's been a while since I've used Pascal, and I'm unfamiliar with the ramifications of the ANSI & ISO standards. Does the provision for directives such as EXTERNAL give implementations a way to support separate compilation? Thanks for any information. John Baugh (jwb@lindenthal.cae.ri.cmu.edu) --
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (05/04/89)
I can address some of your questions. I'm not familar with the ISO standard for Pascal, so I can't speak to that. DOMAIN Pascal has no interpreter that I know of. It does have a powerful and relatively easy to use debugger (there is an initial learning hump, but it's kind of small). The debugger is DEBUG at SR9.7 (which is good) or DDE at SR10.X (which from what little use I've made of it is better, especially for a novice). There are two profiling type tools. HPC is bundled and provides a map of CPU usage within a program. OK for CPU bound programs. DPAK is an extra, but cheap (I think $250 or so?), and is much better in two key ways (many smaller ways too). First, it samples wait states, so if you have a program which is I/O bound or thrashing you can find out where it spending its time. Second, you can map both CPU usage and page faults in a "called from" fashion, rather than for the program as a whole as with HPC. This is especially useful when HPC shows that service routine XYZ, called from 192 separate places in your code, turns out to take all your cpu time. DPAK lets you break down XYZ's time by caller. Other tools and utilities? I'm not familar with much pd stuff for it. There is a Pascal cross-referencer. Sometimes useful. DOMAIN pascal does support separate compilation, but I don't think it's to any standard, although I could be wrong. Good Luck! Dave Erstad DERSTAD@cim-vax.honeywell.com Honeywell SSEC
broman@schroeder.nosc.mil (Vincent Broman) (05/11/89)
Except for the profiler and debugger, which work for C and Fortran also, Apollo Pascal doesn't come with many tools. The code generated is quite fast, and the facilities available through language extensions and pascal-callable libraries are very extensive. (bit ops, address manipulations, graphics, comms, etc.) The language supported as DOMAIN Pascal has only a superficial resemblance to real Pascal. Don't look for conformance to any standard at all. Even the notion of "type" is changed to use structural equivalence instead of name equivalence of types. The compiler supports separate compilation, of course, but does not provide any type consistency checking at all across files. (none!) You have to arrange that yourself by means of include files, make, etc. Procedure/function arguments to procedures and functions are not allowed. New reserved words are defined. Other fun stuff... Don't bother screaming to Apollo about the atrocities they perpetrate upon a nice language. The responses I've gotten from them are either illiterate or else a variant of "That's not a bug, that's a feature." Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 553 1641 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
lehotsky@pmax7.osf.org (Alan Lehotsky) (05/11/89)
After saying a whole bunch of nice things about Apollo Pascal, [like
fast code, extensive extensions, etc], Vincent Broman makes the
mistake of claiming that:
"Don't look for conformance to any standard at all"
I'd like to point out that Apollo's Pascal has been ISO Level 0
compliant for (I think) over two years now.
"Procedure/function arguments to procedures and functions are
not allowed"
This was also fixed at least two years ago (even before it became ISO
conforming). I suspect that he has a very old release of the compiler,
or else he hasn't bothered to RTFM.
Finally, the remark about "illiterate" responses to bug reports is
(hopefully) inaccurate, or else Mr. Broman caught us on an off day.
Most of the UCR responses for Pascal were written by me, or by a
co-worker who happened to be a philosophy major. I won't try too
hard to convince the world that I am literate, but the philosopher
certainly can claim that skill.
And now, penultimately, I'll agree with you that Apollo Pascal contained
more than its share of poorly integrated language extensions. It was
a victim of too many language architects and too little language
architecture!
[I sound like a parent defending his child, huh? So much for ego-less
programming!]
Al Lehotskygrr@cbmvax.UUCP (George Robbins) (05/12/89)
In article <BROMAN.89May10143725@schroeder.nosc.mil> broman@nosc.mil writes: > Except for the profiler and debugger, which work for C and Fortran also, > > The language supported as DOMAIN Pascal has only a superficial > resemblance to real Pascal. Don't look for conformance to > any standard at all. Even the notion of "type"... OSIL: think of it as an Apollo specific Operatings System Implementation Language and it will hurt your head less. The closest parallel might be to some of the degenerate Algol compilers used for similar purposes on Burroughs and HP machines (ESPOL, SPL). -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
slocum@hi-csc.UUCP (Brett Slocum) (05/12/89)
In article <BROMAN.89May10143725@schroeder.nosc.mil> broman@nosc.mil writes: >Except for the profiler and debugger, which work for C and Fortran also, >Apollo Pascal doesn't come with many tools. Well, there's DSEE, which is one of the finest software engineering environments around. We had a massive research contract that produced about 100K lines of code, and maintained/improved another 100K lines of code. We had a fluxuating staff of from 4-16 engineers working on it, sometimes for as little as a month at a time. Using Domain Pascal and DSEE, work progressed so well, that we were able to deliver major enhancements over and above the contract needs, and we came in on-time and within budget. > [. . .] >The language supported as DOMAIN Pascal has only a superficial >resemblance to real Pascal. Don't look for conformance to >any standard at all. Even the notion of "type" is changed >to use structural equivalence instead of name equivalence of types. >The compiler supports separate compilation, of course, >but does not provide any type consistency checking at all >across files. (none!) You have to arrange that yourself >by means of include files, make, etc. Procedure/function arguments >to procedures and functions are not allowed. >New reserved words are defined. Other fun stuff... Since we were working for the DoD, they had fairly strict requirements as to the Pascal we used. Domain Pascal was fine in their eyes. Part of the project was porting this monster of programs to a Vax, running VMS. This task was accomplished in a week, by student aides. 200K lines of code!!! Now, granted, we did make some attempt to write 'standard' Pascal, and not use Apollo-specific calls where avoidable. But this port shows that Domain Pascal is compatible with other Pascals. If you are using multiple source files, you're damn right you should be using include files. How else is the compiler going to figure out what you mean? Are you saying that all modules should be compiled at one time, so that the compiler can do proper type-checking? That's absurd! If you look at C, which was designed for separate compilation, you'll find those same include files all over the place. It's the best way to insure consistency. If you are looking to standards, there is a compiler switch that checks to see if your code conforms to ISO/ANSI standard Pascal. The problem with non-standard Pascal is not in Domain, but in the nature of Pascal itself. There is no standard for multiple source files, system calls, procedure parameters, etc. If you look at Wirth, there is no provision for functions and procedures as parameters. If you take a look at 95% of all Pascal compilers, they will all have the same problems you have just mentioned. If they don't, then many things will be impossible, such as separate compilation. >Don't bother screaming to Apollo about the atrocities they perpetrate upon >a nice language. The responses I've gotten from them are either illiterate >or else a variant of "That's not a bug, that's a feature." Most of the things you are complaining about ARE features. If you use them, then you better realize that you are writting non-portable code (the manual clearly states this). If you don't use them, then you have portable code. It's really a lot easier than you are making it out to be. -- Brett Slocum UUCP: ...uunet!hi-csc!slocum Arpa: hi-csc!slocum@uunet.uu.net
krowitz@RICHTER.MIT.EDU (David Krowitz) (05/13/89)
Actually, I have found Apollo's compilers to be pretty good in the compatibility area. The real problem is this: Everyone I know defines "compatible" as "the way I do it". Apollo's language manuals have all language extensions marked in red type. DEC's Vax manuals (last time I looked at them) had their non-standard language extensions marked in blue. If you avoid those sections, your code will probably be ok ... but there are an awful lot of sections which you would think would be part of the language standard which aren't (would you believe that the logical AND and OR functions aren't part of the Fortran 77 standards? Ever compiler I've met has the functions, but some have "a.and.b", some have "and(a,b)", and some have "iand(a,b)"). Pascal is one of the worst languages in this sense. Much of the language's features that are necessary for building useful programs were loosely defined or not defined at all. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)