home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2458 < prev    next >
Encoding:
Text File  |  1992-08-27  |  2.7 KB  |  57 lines

  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!milo!drew
  3. From: drew@verdix.com (Drew Johnson)
  4. Subject: Re: Need new idea to get around sunada 1.0 [Verdix] error
  5. Message-ID: <1992Aug27.130456.444@verdix.com>
  6. Organization: Verdix Corp.
  7. References: <1992Aug19.185609.10211@src.honeywell.com> <vera.714899225@fanaraaken.Stanford.EDU>
  8. Date: Thu, 27 Aug 1992 13:04:56 GMT
  9. Lines: 46
  10.  
  11. In article <vera.714899225@fanaraaken.Stanford.EDU> vera@fanaraaken.Stanford.EDU (James S. Vera) writes:
  12. >Ack!  The old Verdix bug.  Our group first complained about that bug
  13. >half a DECADE ago.  Bug progress has been made.  Instead of barfing up
  14. >with an assertion error, Verdix is instead (in some future, unnammed
  15. >release) going to issue a standard error message.  Big improvement.
  16.  
  17. We have since decided to make some changes (but the error message will
  18. still get put in too).
  19.  
  20. >
  21. >The problem is not the case statement, per se.  Instead the problem is
  22. >that Verdix has a hard limit on the number of expressions which can
  23. >occur in a subprogram.  The limit is something like 20,000
  24. >expressions.
  25. >
  26. >To get around this bug, you need to break the offending subprogram
  27. >into multiple subprograms.  This, of course, is a pain in the but when
  28. >the subprogram is generated automagicly but gee, you don't expect your
  29. >Ada compiler to compile valid Ada code, do you?
  30.  
  31. It comes down to "how big is too big?"  We used to think that subprograms
  32. like this were "too big".  We are revising this because it is apparent
  33. that this is not the case.  Unfortunately, there is always going to be
  34. a limit to the size of a single body of source that the compiler will
  35. accept.  What will this limit be?  Well, this is difficult to translate
  36. into lines, because a single line can be very complex or very simple.
  37. Right now, I can only tell you that it will be substantially increased
  38. in the next version of the compiler (6.2 for most platforms, SunAda 2.0
  39. for Suns).  Does this mean your code will now compile?  I don't know, because
  40. I don't know just how far over the limit you were.  You might still be
  41. over the new limit.  This is doubtful, but possible.
  42.  
  43. >I've pointed out this Verdix debility to the AYACC folk and they said
  44. >they'll look into it.  I'd put money on it that the AYACC folk code
  45. >around Veridex's bug before Veridex fixes it.
  46.  
  47. Well, we will have beta compilers in the field with this fix in about
  48. a month (less for some platforms).  It would still be a good idea for
  49. AYACC to break up huge subprograms, because even though we will accept
  50. larger ones with 6.2, it is going to be a huge resource sink.  I suspect
  51. that if you compiled this same code with other compilers, you will find
  52. the same thing.
  53.  
  54. Drew Johnson, QA Manager
  55. Verdix
  56. drew@verdix.com
  57.