myb@cernvax.cern.ch (michel bornand) (05/08/91)
Hello everybody. Are there Pascal programmers for Apple II GS? I'd like to get some info from an expert. Seems that nobody uses Pascal on Apple II GS. Is it true? If it's right, can somebody tell me where I can find an FTP site with some Pascal sources? Thank you Micky
stadler@Apple.COM (Andy Stadler) (05/09/91)
In article <5184@cernvax.cern.ch> myb@cernvax.cern.ch (michel bornand) writes: >Hello everybody. Are there Pascal programmers for Apple II GS? >I'd like to get some info from an expert. Seems that nobody uses >Pascal on Apple II GS. Is it true? It's unfortunate, because one of the best IIGS compilers I know of is the MPW IIGS Pascal compiler. We used it for HyperCard IIGS and we were extremely happy with the code it generated. Alas, most GS programmers don't use MPW. >If it's right, can somebody tell me where I can find an FTP site >with some Pascal sources? Unfortunately, I definitely can't share any source! Andy Stadler Apple Computer, Inc.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/09/91)
stadler@Apple.COM (Andy Stadler) writes: >It's unfortunate, because one of the best IIGS compilers I know of is the >MPW IIGS Pascal compiler. We used it for HyperCard IIGS and we were extremely >happy with the code it generated. Alas, most GS programmers don't use MPW. I wonder why not?? That's because we aren't beeg rich software companies with gobs o' bucks to blow on a Mac and MPW (woof! that alone is more expensive that some hard drives). Todd Whitesel toddpw @ tybalt.caltech.edu
nagendra@bucsf.bu.edu (nagendra mishr) (05/09/91)
Well, I for one use PASCAL when I use a GS.
I don't know if anyone has used flux, but I wrote that with
pascal.
Although, I'm great with LISP, I use pascal because there's really no
professional LISP interpreter-compiler for the GS.
Although, I'm 10 times better in C then in PASCAL, I use pascal
because (beleive it or not) I've had better expereinces with TML II
then ORCA/C. I never could manage to compile anything with ORCA/C.
Plus, I'm not sure of this.... so anyone correct me if I'm wrong, I
think that since PASCAL optimization techniques are more STANDARD, any
pascal compiler for the GS will do a better job then any C compiler
just because PASCAL optimization has been around longer and thus more
likely to be incorporated.
So if C compilers on the GS were to imrove, I'm sure that anyone
serious about programming on it would switch. But in our life-time, I
think using a GS means using PASCAL.
nagendrarhyde@ucrmath.ucr.edu (randy hyde) (05/09/91)
>>>>>
Plus, I'm not sure of this.... so anyone correct me if I'm wrong, I
think that since PASCAL optimization techniques are more STANDARD, any
pascal compiler for the GS will do a better job then any C compiler
just because PASCAL optimization has been around longer and thus more
likely to be incorporated.
<<<<<
Two comments- most optimizations are language independent. Things like
common subexpressions, loop invariants, etc. The fact that Pascal has been
around longer than C isn't true. C was actually created in the late 60's and
very early 70's. pascal was invented shortly thereafter. More research has
gone into optimizing C compilers, which is why C compilers, today, generally
produce better code than pascal compilers (MPW Pascal is an obvious exception).
Second-- Pascal, theoretically, can be optimized better than C. C allows
unbridled use of pointers. It is very difficult to optimize such code (correctly)
If Pascal were commercially viable and people were to put the same research into
Pascal as they do into C, code generators for pascal would probably be a little
better than those for C.
*** Randy Hydeq4kx@vax5.cit.cornell.edu (Joel Sumner) (05/09/91)
> In article <5184@cernvax.cern.ch> myb@cernvax.cern.ch >(michel bornand) writes: > >>Hello everybody. Are there Pascal programmers for Apple II GS? >>I'd like to get some info from an expert. Seems that nobody uses >>Pascal on Apple II GS. Is it true? Not true at all. I don't think there are too many people here (certainly not me) who will call themselves "experts" but you can certainly get most any information you need right here. Did you see 'Texter' on comp.binaries.apple2 about a week ago? The Orca/Pascal (and REZ) source will be on comp.sources.apple2 Real Soon Now (I think). Drop me some e-mail if you have any questios, comments, etc.. I will be happy to answer any questions that I am able to. --- Joel Sumner GENIE:JOEL.SUMNER This .sig may not be used q4kx@cornella.ccs.cornell.edu q4kx@cornella for public viewing or q4kx@vax5.cit.cornell.edu q4kx@crnlvax5 rebroadcast without the .................................................... express written consent The impedance of absolutely nothing is 377 ohms. of major league baseball.
jeffh@HyperMail.apple.com (Jeff Holcomb) (05/10/91)
Does the MPW IIgs Pascal compiler do any optimizations on the code? If so, what kinds? I don't know about Orca/Pascal, but Orca/C is definitely not an optimizing compiler. The same for MPW IIgs C, I think. -- Jeff Holcomb x4-0841 Apple ATG System Software jeffh@HyperMail.apple.com
stadler@Apple.COM (Andy Stadler) (05/10/91)
In article <13419@goofy.Apple.COM> jeffh@HyperMail.apple.com (Jeff Holcomb) writes: >Does the MPW IIgs Pascal compiler do any optimizations on the code? If so, >what kinds? I don't know about Orca/Pascal, but Orca/C is definitely not an >optimizing compiler. The same for MPW IIgs C, I think. The MPW IIGS Pascal compiler contains a huge library of "code templates" which allow it to select the best series of opcodes for a given set of operations. Each template includes information on the size (# of bytes) and speed (# of cycles) and the compiler iterates over every set of templates which could work, and then chooses the set which have the best (speed or space, depending on a command-line option). These templates range from the mundane to the complex.... But you'd be amazed at some of the templates we threw in. Some examples: IF var = 2 THEN ... is coded as lda var, dec, dec, bne. Branches are ALWAYS short unless the distance requires long. CASE statements are generated as tables when the selectors are dense, and computed IF's when they are sparse. In addition, "fast math" is used (it wouldn't be legal pascal for computations but it takes advantage of 816 ALU quirks). Many branches are generated directly using status register flags. For example, most compilers will compile IF var > 0 using a subtract of zero! But PascalIIGS instead uses lda var, bmi, beq. It knows that load's set the flags (many compilers don't). Even better, it knows that for many long integer compares, you DON'T need to look at the low word. For example, IF longVar < 0 can be coded as lda longvar+2 bmi Every other compiler I've ever seen loads all 32 bits, and performs a 32 bit comparison of the value. Long integer math is also quite efficient. Adds and subtracts of longs with constants are extremely optimized, depending on the constant. For example, if you add 1 to a long integer in A and X, it's just inc a bne *+3 inx And if you added 100 to the long, it would be clc adc #100 bcc *+3 inx Once again it's the only compiler I've looked at (on the GS) which performs these types of optimizations. All of the examples I've listed so far are "code generation" optimizations. In addition, the "front end" (the language parser) is also extremely efficient. It actually does things like rearranging code to put things in the most efficient order, and actually throwing out unused code. A simple "throwaway" example might be the code REPEAT UNTIL FALSE; an endless loop. Most compilers would generate: loop lda #0000 cmp #0000 beq loop But pascal IIGS recognizes this and just generates loop bra loop Finally, there are some simple rules programmers can follow which will help the compiler generate the best code possible. If there's anyone out there actually using this compiler, let me know and I can explain some of them... Which brings up the point, a lot of people misunderstood an earlier posting of mine. I said something like "Alas, not too many programmers use MPWIIGS". I did NOT mean this as a plug for MPW or buying Macintoshes. All I meant to say was that there's a nice compiler out there, and it's too bad it's on a development system which isn't widely used. That's all. A hint: Try not to be so defensive, folks. Focus some of that great energy on writing the next great GS applications! Andy Stadler Apple Computer, Inc. P.S. One final word on HLL vs. ML: Remember to choose the right tool for the job. AND, remember that a single program doesn't have to be written in a single language. Assembly isn't the perfect language for every programming problem. Neither are C or Pascal. Use each when appropriate and let your linker sort out the results.
jeffh@HyperMail.apple.com (Jeff Holcomb) (05/10/91)
References:<14308@ucrmath.ucr.edu> <13419@goofy.Apple.COM> <52655@apple.Apple.COM> In article <52655@apple.Apple.COM>, stadler@Apple.COM (Andy Stadler) writes: > > The MPW IIGS Pascal compiler contains a huge library of "code templates" which > allow it to select the best series of opcodes for a given set of operations. > Each template includes information on the size (# of bytes) and speed (# of > cycles) and the compiler iterates over every set of templates which could > work, and then chooses the set which have the best (speed or space, depending > on a command-line option). These templates range from the mundane to the > complex.... These all seem to be similar to peephole optimizations...are any other optimizations done on the tree-code (like common subexpression elimination, data flow analysis, or loop optimizations)? I have had quite a bit of experience with the Gnu C Compiler and I'm used to the type of optimizations it does, so that's the main reason I'm curious about the MPW IIgs Pascal compiler. > Finally, there are some simple rules programmers can follow which will help > the compiler generate the best code possible. If there's anyone out there > actually using this compiler, let me know and I can explain some of them... I'd be interested in seeing these... -- Jeff Holcomb x4-0841 Apple ATG System Software jeffh@HyperMail.apple.com
gwyn@smoke.brl.mil (Doug Gwyn) (05/11/91)
In article <14308@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >Two comments- most optimizations are language independent. Things like >common subexpressions, loop invariants, etc. That's all correct, within the context of "Algol-like" languages. On several systems, compilers for languages like Fortran, Pascal, and C all share a common "back end" (optimizer and code generator), with only the "front end" (language parsing and semantics) differing. >The fact that Pascal has been around longer than C isn't true. C was >actually created in the late 60's and very early 70's. pascal was invented >shortly thereafter. A preliminary version of Pascal was drafted in 1968, the first Pascal compiler became operational in 1970, the Pascal User Manual and Report was published in 1971, the Revised Report was published in 1973, and the second edition of the Pascal User Manual and Report was published in 1974. C was created in 1972 (via evolution from B, which was written in 1970), and during 1977 work on porting UNIX led to refinements that are reflected in the first edition of K&R's "The C Programming Language", published in 1978. Thus, Pascal is a couple of years older than C. >More research has gone into optimizing C compilers, >which is why C compilers, today, generally produce better code than pascal >compilers (MPW Pascal is an obvious exception). I don't know that any blanket statement can be made, other than that obviously compilers that get more attention have a good chance of producing better code. A lot of Apple developers came from a Pascal heritage (PARC, etc.) and thus cared more about their Pascal compilers than C compilers. In recent years in the IBM PC world, C has received more attention than Pascal. >Second-- Pascal, theoretically, can be optimized better than C. C allows >unbridled use of pointers. It is very difficult to optimize such code >(correctly) I don't know what "unbridled" is supposed to mean, but optimization is not all that difficult, just constrained to take possible aliasing into account. Pascal also supports pointer types. Their main differences from C are: (1) There is no "address-of" operator in Pascal; instead, pointed-to variables (but not the pointers themselves) must be dynamically allocated by "new". (2) There is no automatic conversion of a reference into a pointer. This is particularly evident when passing a parameter to a function. The optimization issues are similar. Pointer value parameters and variable parameters in Pascal can be aliased, and code generation needs to take this into account, just as for C. >If Pascal were commercially viable and people were to put the same research >into Pascal as they do into C, code generators for pascal would probably be >a little better than those for C. Pascal HAS been commercially important, particularly in Europe. Again, I don't think there is any point in trying to make blanket judgements about the quality of code generation for Pascal vs. C.
gwyn@smoke.brl.mil (Doug Gwyn) (05/11/91)
In article <13419@goofy.Apple.COM> jeffh@HyperMail.apple.com (Jeff Holcomb) writes: >Does the MPW IIgs Pascal compiler do any optimizations on the code? If so, >what kinds? I don't know about Orca/Pascal, but Orca/C is definitely not an >optimizing compiler. The same for MPW IIgs C, I think. Wrong -- ORCA/C definitely performs several kinds of optimization, several of which can be selectively enabled/disabled via "#pragma optimize ...". The default is to disable most optimizations, which may be where you got your idea.
gwyn@smoke.brl.mil (Doug Gwyn) (05/11/91)
In article <NAGENDRA.91May9015112@bucsf.bu.edu> nagendra@bucsf.bu.edu (nagendra mishr) writes: >Although, I'm 10 times better in C then in PASCAL, I use pascal >because (beleive it or not) I've had better expereinces with TML II >then ORCA/C. I never could manage to compile anything with ORCA/C. >Plus, I'm not sure of this.... so anyone correct me if I'm wrong, I >think that since PASCAL optimization techniques are more STANDARD, any >pascal compiler for the GS will do a better job then any C compiler >just because PASCAL optimization has been around longer and thus more >likely to be incorporated. >So if C compilers on the GS were to imrove, I'm sure that anyone >serious about programming on it would switch. But in our life-time, I >think using a GS means using PASCAL. There is no such thing as "PASCAL optimization", and that whole argument is bogus. Any decent compiler implementation for either language is likely to perform similar optimizations. ORCA/C release 1.0 was, in my opinion, too buggy to be useful. Release 1.1 was better (free upgrade!) but I still couldn't get it to properly translate a lot of code that should have worked. Release 1.2 has fixed most of the really bad bugs in ORCA/C, although there are still several bugs (all the ones I know of have been reported back to ByteWorks and ought to be fixed in the next release, which may not occur for a while). I've found that I can get most of my applications to compile correctly under ORCA/C, although I often have to work around the remaining bugs. If you have a properly suspicious attitude and a clear grasp of what a C compiler is and is not supposed to do, you should be able to use ORCA/C for large programming projects. I would suggest implementation in relatively small pieces, with testing of each piece that is thorough enough to uncover problems caused by compiler bugs.
rhyde@ucrmath.ucr.edu (randy hyde) (05/13/91)
Pascal has been commercial successful in the U.S., as well. But its popularity waned over the past decade (Turbo Pascal, not withstanding). As for pointers in C vs. pointers in Pascal, all Pascal pointers are anonymous (as you pointed out, there is not address-of operator in Pascal; except pass by reference parameters). This eliminates problems with aliasing which is very difficult for an optimizing compiler to handle. Yes, compiler writers can give blanket judgements about this one, especially since C programmers tend to use pointers for just about everything (e.g., they'll typically use a pointer rather than a simpler, and easier to optimize, array access). The fact that commercially available C compilers tend to generate better code is a testament to the work that C compiler writers have put into their products.
stadler@Apple.COM (Andy Stadler) (05/14/91)
In article <16114@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Pascal also supports pointer types. Their main differences from C are: > (1) There is no "address-of" operator in Pascal; instead, > pointed-to variables (but not the pointers themselves) must be > dynamically allocated by "new". Actually, the majority of currently available Pascal compilers DO support this operator. It's often expressed as "@" and is syntactically equivalent to the "&" operator in C. And, since we're talking about Apple programming here, there's an alternative to use of the "New" procedure - you can use the system memory manager. In fact, I recommend that people NOT ever use the New/Dispose/Mark/Release suite; because there's a pretty large of hunk of library code that gets linked in to support them. Just stick with NewHandle and let the ROM do the work.... (This generalization valid for IIgs AND Mac programming.) Andy Stadler Apple Computer, Inc.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/14/91)
stadler@Apple.COM (Andy Stadler) writes: >And, since we're talking about Apple programming here, there's an alternative >to use of the "New" procedure - you can use the system memory manager. In >fact, I recommend that people NOT ever use the New/Dispose/Mark/Release suite; >because there's a pretty large of hunk of library code that gets linked in >to support them. Just stick with NewHandle and let the ROM do the work.... >(This generalization valid for IIgs AND Mac programming.) Hear, hear. I _never_ use the Orca/C malloc routines, I include my own that call NewHandle directly. free() is not that fast (it has to do a FindHandle) but well-written programs should avoid calling those routines often anyway. (If you really need allocation speed you should be allocating big chunks from the system and managing them yourself.) Todd Whitesel toddpw @ tybalt.caltech.edu