Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!braner From: braner@batcomputer.tn.cornell.edu (braner) Newsgroups: comp.sys.atari.st Subject: Re: Laser C question (also GNOME) Message-ID: <4479@batcomputer.tn.cornell.edu> Date: 20 Apr 88 13:36:59 GMT References: <211@bdt.UUCP> Reply-To: braner@tcgould.tn.cornell.edu (braner) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 54 Keywords: Laser C, GNOME, hard disk, DA Summary: Laser C does work from HD, new GNOME version [] The early version of Laser C (1.0) always spun drive A: for a second but then DID go and load everything from the hard disk (assuming you set all the paths and tool locations, under the OPTIONS menu, to drive C:, and then clicked on "SAVE CONFIGURATION".) The newer release (1.01, I got it in the mail together with the manual) seems to have fixed that bug altogether. There IS a problem with running some TOS programs from inside Laser C's STDIO window. I never figured out when it is safe to just type the program's name, and when you have to precede it with "tos" (giving it the whole screen but loosing the ability to capture the output in the STDIO window, which is back-scrollable and cut-and-pasteable). By "not safe" I mean that the output rolls off the window. There is also a problem with TTP programs. Some (e.g. my MORE utility) do not get the command-line arguments correctly. TTP programs compiled with Laser C work fine. MORE was written in AL and it looks in the base page for the unaltered command line. I havn't had the time to figure out what exactly happens when you invoke it from the STDIO window but it does not get the command line right, probably gets a garbage filename to print, and ends up with a "TOS error" message. As for speed: yesterday I timed Laser C (on a 1040 + SH204) doing a complete recompile of GNOME (190K source code in 13 files, 53K output binary). It took just over 3 minutes. Not bad at all, although Turbo C on a rather fast IBM-AT clone with a much faster HD (but no caching of any sort!) did it in 90 seconds. Execution speed? An optimized C version of the Fast Hartley Transform (see April BYTE) transformed a 512-point data set on my ST in 1.7 seconds, everything in double precision software FP. (1.2 seconds for repeated calls with the same N, keeping the work arrays in-between!). Compare that with the 27 seconds quoted in the BYTE article for the Pascal version (on a Macintosh, i.e. similar CPU power, although it might have used (in)SANE...). - Moshe Braner 69 Ringwood Rd., Freeville, NY 13068 (607) 347-4573 (Home) (607) 255-9401 (Work) (ARPANET) or (BITNET) PS: GNOME 2.2 is almost ready, and it comes in a DA flavor too. Should I post it? How much memory should the DA hog? (It must allocate a large text buffer upon boot since DA's are not supposed to call Malloc() later. My current setup uses a 90K buffer (the program uses another 50K) and one can only edit about 50K of text in there due to both malloc- and data-structure overhead. The plus is that the text stays in it between separate openings of the DA.) Warnings to users of GNOME 2.1: do not press ^C to try and abort numeric-prefix-entry mode, and do not press the up or down arrows when choosing a buffer to go to if there is no other buffer. (These and other bugs are fixed in 2.2.) If you know of any other bugs in GNOME 2.1, _PLEASE_ tell me soon. Thanks.