From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/08 Message-ID: X-Deja-AN: 296319580 References: Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-12-08T00:00:00+00:00 List-Id: In article , stt@houdini.camb.inmet.com (Tucker Taft) wrote: > Joe Gwinn (gwinn@res.ray.com) wrote: > > : ... > : Exception handlers. We were declaring a number of exception handlers at > : the beginning of each and every module, so every time the module was > : entered, the context had to be saved, and every time the module was > : exited, the context was popped off the exception stack and discarded, > : regardless of if an exception was ever raised. This was easily solved; > : now, only tasks declare exception handlers, not modules. > > I believe Green Hills is beginning to work on an implementation of > exceptions that uses a PC-indexed table rather than setjmp/longjmp. > However, as Robert points out, using such a table is significantly more > machine-dependent, and generally requires coordination with the linker > and more complex out-of-line algorithms in the run-time. This sounds good, but I would guess that it won't arrive in time for the current project. Probably two thirds of the high-end embedded realtime market will target the PowerPC, so that's one place where some machine dependency may be worthwhile. > As far as enumeration types, as others have pointed out, the Ada 95 > standard requires that the internal codes for enumeration types are > contiguous and start at zero, so you are not in any danger if you leave > out your "confirming" representation clauses. It would be nice if > our front end recognized "confirming" enumeration representation > clauses, but as usual, there are many possible "optimizations" > and this one never made it to the top of the list. > One might argue that this is not really an optimization, but > it does require special code to recognize, and so represents > yet another "special case" that you have to decide the priority > of recognizing. The key issue was that we had no way of knowing the dire consequences of this innocent looking bit of standard Ada, until we had gone a fair distance down that wrong road. One wonders what other surprises lay in wait. A number of folk have cited chapter and verse that enumerations do start at zero if left alone. This was not widely known, apparently, perhaps because Ada83 didn't govern this. > : ... > : Memory Management. The Ada Runtime System makes extensive calls to the C > : functions malloc() and free(), a cause for worry. > > It might be interesting to identify where this is really happening. > Were these from calls in your source code to "new" and instances > of Unchecked_Deallocation, or were they "implicit"? They were implicit. Our programmers are in fact forbidden to deallocate using the Ada RTE, to avoid fragmentation etc. The profiler caught no miscreant applications. Now that use of exception handlers and rep specs on enumerations have been restricted, the calls to malloc and free dropped to near zero. We will trap and inspect all callers of free, so if any of our programmers are using malloc/free, they will be caught. What to do about Ada RTE implicit use of malloc/free is quite another issue. By the way, the issue is use of free, not malloc per se. The applications are allowed to allocate structures during startup, but they are not allowed to use free. They must instead keep the memory and manage it themselves, using a simple and obviously fragmentation proof algorithm. > We have versions of our runtime which only use the heap "implicitly" > for task control blocks (and these are recycled explicitly rather than > using free) and for task stacks (and again, these are recycled rather > than using free). So the only calls on "free" should be in response > to an explicit call on an instance of unchecked-deallocation. This sounds good, but I don't know that it's draconian enough for embedded realtime. I don't know that I would give random users the choice of versions. As I said above, we forbid users to use deallocation (and thus free). Is that runtime set up so I can flip a compiler switch to catch any users that didn't understand that they are not allowed to use deallocate? > ... Furthermore, > we also have our own implementation of malloc/free which uses > "quick fit" rather than the traditional C "first fit." This may > be the algorithm Quick-fit algorithms also can fragment; what's different is the spectrum of request sizes needed to provoke trouble. Actually, many quick-fit algorithms generate worse fragmentation than the worst-fit algorithms. All the variable-length memory management algorithms have their advantages and disadvantages, but the biggest disadvantage is that they are inherently statistical in nature, so there is always a request spectrum that will kill them. Historically, we have found that the only approach that always works, even when the system is straining under the load, is a fixed-block allocator offering three or four project-specific sizes of block. Joe Gwinn