home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / ada / 4044 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  3.8 KB
  1. Path: sparky!uunet!dtix!mimsy!alex
  2. From: alex@cs.umd.edu (Alex Blakemore)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: ASIS (Was Re: IrisAda) REPOST - REFORMATTED TO 80 COLUMNS
  5. Message-ID: <63640@mimsy.umd.edu>
  6. Date: 22 Jan 93 21:15:38 GMT
  7. Sender: news@mimsy.umd.edu
  8. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  9. Lines: 67
  10.  
  11. ryer@inmet.camb.inmet.com (Mike Ryer) writes:
  12. > ASIS has a cost beyond the dollars you pay for it.  It
  13. > can result in slower compilers and larger program libraries.
  14. > Our compiler (for MVS) currently generates DIANA; it would be a very simple
  15. > matter to add ASIS generation -- just send money.  
  16.  
  17. In Intermetric's case, since you already store DIANA, providing an ASIS
  18. interface to the DIANA should not add significant time, space, costs to
  19. your compiler beyond what's there to create and traverse DIANA.  DIANA is
  20. a very rich intermediate form.  You are correct that a vendor which
  21. already used a lean intermediate form may have more work & tradeoffs to
  22. make to support ASIS.
  23.  
  24. One important point - ASIS is NOT an intermediate form or a data structure
  25. (like DIANA).  It is a relatively simple INTERFACE that allows you to
  26. query information from whatever intermediate form the compiler uses in a
  27. standard way.  Depending upon the details of the particular intermediate
  28. form, supporting ASIS may be simple or complex.  If the information is
  29. already stored in the intermediate form, the compiler should not have to
  30. be made slower and more complex (regardless of the complexity of the ASIS
  31. interface) The compiler may not need to be changed at all.  If ASIS
  32. requires some information that is not currently stored, there are several
  33. approaches.
  34.   - modify the compiler to store the needed info,
  35.   - recompute the info on demand
  36.   - not implement the particular ASIS feature
  37.     (several things have been made optional that compiler vendors
  38.      typically dont store, there are query routines that allow tools to
  39.      test if an implementation does this)
  40.  
  41. For example, source position info may not be preserved by some compilers.
  42. If its not, dont implement the package ASIS_Text that provides that info.
  43. Tools can call the routine IS_Text_Supported to check whether that info is
  44. available.  Tools that dont need source position info can work.  Other
  45. tools wont & people that want those tools to run can then pressure/pay you
  46. to provide that feature.
  47.  
  48. I know one very fast lean compiler that already has an intermediate form
  49. that will easily support most of ASIS.  Most compiler vendors already
  50. provide some interface, but its always a different one.  Until we have
  51. some kind of standard, its very expensive and difficult to develop Ada
  52. tools - and when you are done they only work with one compiler.
  53.  
  54. > In my opinion, ASIS has been defined as "everything that Telesoft and Rational
  55. > happen to have in their libraries", rather than "everything that a reasonable
  56. > tool vendor needs and cannot easily compute for him/herself".
  57.  
  58. ASIS is evolving - and the latest drafts have tried to address your
  59. concerns in several ways.  Several compiler vendors have attended working
  60. group sessions and pointed out what is hard or easy for them to support.
  61. One concept that is shaping up in 1.1 is to provide a standard interface
  62. to some information that could be computed (with difficulty) from lower
  63. level ASIS primitives.  There would be a public implementation of this
  64. higher level layer that any vendor could use - so they only have to
  65. provide the primitives
  66.  
  67. Perhaps someone from Intermetrics could attend an ASIS working group
  68. meeting and contribute to developing ASIS into a practical standard.
  69.  
  70. --
  71. ---------------------------------------------------
  72. Alex Blakemore   alex@cs.umd.edu NeXT mail accepted
  73.  
  74.  
  75. -- 
  76. ---------------------------------------------------
  77. Alex Blakemore alex@cs.umd.edu   NeXT mail accepted
  78.