home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 17790 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  1.6 KB
  1. Xref: sparky comp.sys.amiga.programmer:17790 comp.sys.amiga.misc:19042
  2. Path: sparky!uunet!oracle!unrepliable!bounce
  3. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.misc
  4. From: dnavas@oracle.uucp (David Navas)
  5. Subject: Re: Advice to SAS/C 5.10b users
  6. Message-ID: <1992Dec24.190502.12582@oracle.us.oracle.com>
  7. Sender: usenet@oracle.us.oracle.com (Oracle News Poster)
  8. Nntp-Posting-Host: mailseq.us.oracle.com
  9. Organization: Oracle Corporation, Redwood Shores CA
  10. References: <BzDM7J.5nG@csugrad.cs.vt.edu> <1992Dec18.154954@rbg.informatik.th-darmstadt.de> <BzGqrA.4qI@unx.sas.com>
  11. Date: Thu, 24 Dec 1992 19:05:02 GMT
  12. X-Disclaimer: This message was written by an unauthenticated user
  13.               at Oracle Corporation.  The opinions expressed are those
  14.               of the user and not necessarily those of Oracle.
  15. Lines: 19
  16.  
  17. In article <BzGqrA.4qI@unx.sas.com> jamie@cdevil.unx.sas.com (James Cooper) writes:
  18. >FYI, in general, it should NEVER be necessary to use CODE=FAR -or- DATA=FAR,
  19.  
  20. As long as you don't use SAS' included proto files that define the library
  21. bases without the __far keywords.
  22.  
  23. :)
  24.  
  25. >you should still be able to compile without the "xxx=FAR" switches, in which
  26. >case your code will be smaller and a bit faster than if you use the "xxx=FAR."
  27.  
  28. Actually, I've found it often helps, and very rarely ends up hurting.
  29. These things seem to depend on what other options you are using....
  30.  
  31. Of course, most of my modules are less than 8k (when optimized), so there's
  32. almost as much difference in the overhead of the startup than anything else....
  33.  
  34. David C. Navas                        dnavas@oracle.com
  35. Working for, but not speaking on behalf of, Oracle Corp.
  36.