lucifer@world.std.com (Kevin S Green) (02/13/91)
In article <49059@apple.Apple.COM> stadler@Apple.COM (Andy Stadler) writes: >Yep, that's exactly the right thing to do. Here's actual real live source >code from HyperCardIIGS, where we needed to do exactly what you describe: > > hyperCardResFile := startStopInfo.resFileID; > {$IFC Internal } { convert the read-only resource fork to read/write } > CloseResourceFile(hyperCardResFile); > hyperCardResFile := OpenResourceFile(read+write, NIL, hyperCardAppName); > IF _toolErr <> 0 THEN hyperCardResFile := 0; > startStopInfo.resFileID := hyperCardResFile; > {$ENDC } > Just a simple question Andy, (Not a flame!). Why did the HC//gs team go with pascal as the language for writing the program? Was C considered but lost out? Was Assembly also avoided? Just for trivia's sake, I'd like to know some of the thought behind the designing of HC//gs. -- Kevin S. Green / lucifer@world.std.com / {xylogics;uunet}!world!lucifer Party naked... /AOL: Gargoth / Pro-line: kgreen@pro-angmar
stadler@Apple.COM (Andy Stadler) (02/13/91)
In article <1991Feb12.223449.9492@world.std.com> lucifer@world.std.com (Kevin S Green) writes: > >Just a simple question Andy, (Not a flame!). Why did the HC//gs team >go with pascal as the language for writing the program? Was C >considered but lost out? Was Assembly also avoided? Just for >trivia's sake, I'd like to know some of the thought behind the >designing of HC//gs. > HyperCardIIGS is actually written in a combination of Pascal and assembly language. I tend to do just about all projects in some combination of high-and-low level, because you really can utilize each language for its strengths and weaknesses. The programming model we chose is a completely Pascal-based program, with all code structure, flow of control, and variable declarations in the Pascal section. Assembly is used only for individual speed-sensitive routines which always use Pascal calling sequences and rarely call other assembly routines. We structured the program this way for two reasons. First, a good rule of thumb is that a program will spend 90% of its time in 10% of the code. Writing the entire program in a difficult-but-fast language is a waste of time. Better to write the whole thing in a high-level easy to read and write language and then, once the bugs are worked out from the basic design, go back, MEASURE performance, identify critical sections, and rewrite or redesign. This leads to the second reason, which is that you can easily move a Pascal routine into assembly by rewriting it, commenting out the original source, and changing the FORWARD declaration to EXTERNAL. No other code needs to be modified, and you can debug the new subroutine in a fairly isolated fashion. Now, why did we choose Pascal instead of C? For a number of reasons.... 1. The original program was written in Pascal for the Macintosh. It was enough work just moving it to the new platform. By using the same language we could move entire sections (especially calculation and manipulations of internal data structures) with cut-and-paste. If we used C we'd have had to literally rewrite every single line. 2. We used the MPW IIGS programming environment to create this program. I'm not as familiar with the compilers available for APW & ORCA, but in the MPW world, we have two: A not-so-great, non-standard C compiler, and an extremely good very standardized Pascal compiler. The MPW IIGS Pascal compiler is the same front end used for the MPW (Mac) Pascal compiler - which gave us better compatibility with the Mac HyperCard source code - and an all-new code generator which is the best I've ever seen for the 65816. There are of course speed and space problems using any compiler, but we felt the MPW IIGS Pascal compiler was about the best we could get. An example of the differences: I compiled a sample XCMD with the Pascal and C compilers under MPW. Measuring the compiled code only (not anything linked in from the libraries) the C object code was TWICE as large. This is a very distorted example, and I'm sure a longer XCMD would show less of a difference (having much more actual compiled code and less boilerplate header- type code), but nonetheless there's a significant advantage to the Pascal compiler. To summarize, there were pragmatic reasons for choosing Pascal, mostly the superior compiler, and the language of the original program. However at this point I should mention that I've always preferred Pascal and given a situation with all other factors equal, I'd probably choose it anyway. And I'd like to reiterate the concept of MEASURE, then OPTIMIZE. Experience shows you CANNOT predict the bottlenecks in your program. ANY sort of hard- ware or software timing tool which can be used to measure your program's performance will add greatly to your ability to CHOOSE which sections to optimize. Believe me, you will get some surprises. Andy Stadler HyperCardIIGS Team Apple Computer, Inc.