Path: utzoo!attcan!uunet!lll-winken!ames!ig!bionet!agate!ucbvax!tut.cis.ohio-state.edu!rutgers!njin!princeton!phoenix!kadickey From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Newsgroups: comp.sys.apple Subject: Re: Disassemblers Summary: TML Pascal Message-ID: <7820@phoenix.Princeton.EDU> Date: 19 Apr 89 05:15:05 GMT References: <2584@puff.cs.wisc.edu> Reply-To: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) Organization: Princeton University, NJ Lines: 61 Since everyone seems to have the opinion that there is something seriously wrong with TML Pascal (but without any specifics), I will fill in what I know about it. I am taking a CS course that requires programs to be written in Pascal-- so I decided to buy TML. I'd also like to get a decent C-compiler, but 1) they are a bit expensive and 2) everyone seems to agree that they are quite slow. TML Pascal 1.50 (the version I have...it would seem to be the latest) allows very simple access to Toolbox routines, easy creation of NDAs and CDAs, and DEFINITELY encourages the programmer to use the GS programming environment (in fact, a bit too much. A 'standard' Pascal program has its default window to be the SHR screen--which scrolls pitifully slow. To use text, you must start up the TextTools toolset and deal with it all yourself!). It has a few significant bugs. I can't seem to print my program out properly on my Imagewriter II--lines seem to get lost at random. This could be partly my fault (I've deleted most of the GS/OS system disk since I've placed it on my /ROM drive). But, the editor environment sometimes 'crashes' at random--with the crash usually resulting in the mouse still moving around, but none of the menus will open up (and it isn't crashed into the monitor...). There is a neat feature of 'Check Syntax' which checks your program for obvious syntactic mistakes without taking the extra time to actually compile it--but using Check Syntax makes a crash 100 times more likely...so I don't use it. It compiles relatively fast (6,000 line/min? I'll do some timings later), and produces reasonable code (I wrote a quicksort procedure with it that took just 3.6 seconds to sort 10,000 random integers. Handcoding the same procedure in assembly, with some neat tricks, only cut the time down to 1.51 seconds...so I'd consider that fairly good code). A neat feature is 'keyboard break' which allows you to hit ctrl-C at ANY TIME to stop a program (though, obviously, this makes your program huge and runs about 5 times slower...but it's a very handy feature). The most unfortunate aspect of the program is floating point numbers. All floating point calculations are done in Extended format (10 BYTES!!) and the program doesn't seem to properly support single of double sizes (compiling a program which has Singles or Doubles always leads to a link-time error of 'No _vardbl defined' or something like that--indicating that something important is missing.) Since all real calculations are done in 10-byte mode, and I can't use singles or doubles for storage even, arrays of reals become HUGE and calculations are slow. TML supposedly (and from the times, I believe it) uses SANE for everything, so getting a coprocessor would make it fly. TML Pascal allows variables to be placed in different segments (and code in different ones too), which the system loader then places in memory at the proper places when it's loaded. Thus, with a few extra declarations, individual arrays up to 64K are easy to handle. A *VERY* annoying 'feature' of the compiler is this: I've declared VALUE to be a Real. I accidentally have a statement VALUE := 0; (Instead of the proper 0.0) The compiler doesn't flag this as an error--so you'd think it would properly convert the 0 integer value to a real--but it doesn't! It just places the INTEGER VALUE 0 into VALUE, which isn't 0.0 at all (the upper bytes aren't changed!) This is always a very hard bug to track down...the compiler should flag this. That's my review of TML Pascal...if anyone has anything to add, please do so. Kent Dickey (KADICKEY@phoenix.Princeton.EDU)