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,37b5f16b9be86fec X-Google-Attributes: gid103376,public From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: ada -> C translator Date: 1997/04/04 Message-ID: <5i2ofl$qn6$1@news.nyu.edu>#1/1 X-Deja-AN: 230665522 References: <5i243c$i1h@mulga.cs.mu.OZ.AU> Organization: New York University Ultracomputer Research Lab Newsgroups: comp.lang.ada Date: 1997-04-04T00:00:00+00:00 List-Id: In article <5i243c$i1h@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: >>If you get into the business of generating very low level C code, then >>it may well be highly target dependent (e.g. have made decisions about >>representation of primitive data items). > >Yep, if you want efficiency, you may need to use machine-dependent >code. However, you can get this without sacrificing portability >if you keep the less efficient but portable C code as a fallback. No, you missed Robert's point. The issue isn't support of non-portable constructs, but representation of data items. Specifically, discriminated records. You will probably be forced to generate code that has specific offsets encoded into it. These offsets will depend on the sizes of primitive datatypes. It just *might* be possible to write all these in terms of type sizes at the C level and make it portable, but that's *really* hard if possible at all.