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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,17395bd9bffaca19 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That) Date: 1997/01/13 Message-ID: <5bdg7d$nhk@top.mitre.org>#1/1 X-Deja-AN: 209686564 sender: Mike Brenner references: <97011214115169@psavax.pwfl.com> organization: The MITRE Corporation, Bedford Mass. newsgroups: comp.lang.ada Date: 1997-01-13T00:00:00+00:00 List-Id: My experience with 1553 indicates the following: (a) The bit structures are easier to deal with in Ada-95 because of the modular types. (b) To be compatible with C or FORTRAN or JOVIAL at the other end, let the high-order bit be always zero (c) The hard part is the conversion from 1553A to 1553B which requires a method of using the extra wire when no response is received on the first wire, for extra reliability. It is easier to design this in First, rather than add this in later. (d) While everyone frowns on overlaying data using address clauses, I have seen them used on 1553A or 1553B drivers on MIPS, 80x86, and 680x0 CPUs in Ada, with no efficiency hit or reliability problems. In all three compilers, there WAS an efficiency hit for using an unchecked_conversion: it did a copy operation for most or all accesses. (e) Getting rid of the tag is a bigger problem than you indicate because the machine-independent specification of how to represent the tags is not in the Ada Standards, but in the CORBA standard. Since not everyone on the other side will have access to CORBA, you should not use tags, discriminants, or unconstrained elements in the message data structures themselves. Instead, ACCESS EACH ELEMENT through an object oriented interface (a get function and a set procedure). This use of object oriented design forgives many coding sins and deals with the foibles of many languages, operating systems, message formats, and hardware protocols like the 1553. (f) You are absolutely right about avoiding dynamic allocations because of unpredicatability of time, even in the fastest systems. You are also right that a good approximation to the amount of time your system will take is proportional to the number of copies of the data you make. Therefore, at this first approximate level, reducing the number of copies is indeed critical. (g) But in these days of plummeting memory chip prices, and continued blossoming of CPU speeds, we should not restrict ourselves to slow, small-RAM hardware solutions. A MIPS R10000 chip today with dual ported memory for the buffers is no more expensive than the LSI-11, 680x0, or Spark chip solutions were last year. The new desktop Pentium PRO 200MHz chips with PCI bus and memory mapped I/O to dual ported memory can copy the buffer in zero time or less (because of overlapping, pre-reading, hardware memory protection, write-back cache larger than the size of the buffer, and mapping registers). The translation lookaside buffers for virtualizing the Spark, MIPS, TI, and Alpha chips, when combined with 2 levels of cache can give statistical determinate memory access of a single cycle, with the worst case only 8 cycles. All of these brands of chips permit the addition of DMA channels which can read and write memory in parallel. These are just some of the more common brands of chips and there are many more brands and many custom chips, ASICs, PALs, etc. Do not limit yourself to fore-ordained hardware. Be flexible enough to recognize that any Ada procedure or task can be replaced by a chip. For example, they have RISK chip CPU boards that plug into a PC, that you talk to through memory mapped RAM locations. Sometimes the best software solution is improved hardware.