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: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: ada -> C translator
Date: 1997/04/04
Message-ID: <dewar.860160369@merv>#1/1
X-Deja-AN: 230675410
References: <33436B29.41C6@sema-grenoble.fr> <E833ux.337@world.std.com>
 <dewar.860115718@merv> <5i243c$i1h@mulga.cs.mu.OZ.AU>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-04T00:00:00+00:00
List-Id: <comp.lang.ada>


Fergus said

<<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 the point. I am not talking about using non-portable
constructs. The code you generate could be 100% ANSI code, but still
not be portable in the sense of being movable to another target
environment. For example, specific shifts might be generated whose
direction depends on the endianness of the target machine. Such code
could be ported, but would not behave as expected on a target of the
other endianness.

The point here is that if you are generating *really* low level C, it
will start having the same kind of knowledge of the target architecture
as a real object code generator would.

Here's another example. You might decide to model a variant record as
an array of chars in the C code, to avoid the difficulty of having to
give a high level model. But you know the alignment requirements for
such an array of bytes and you put in alignment fill bytes explicitly
into your data structures.

Here's another example, you are generating calls to COBOL for implementing
the IS annex. You know on a specific target what COBOL passes by value
and what it passes by reference, and exactly how it orders its arguments
etc. You generate C code that reflects it. The C code is portable from
the point of view of C semantics, but might well not be able to interface
properly with the COBOL compiler on the new target.

There are many many more such examples

Fergus, what you say is true for general C code that tries to get better
efficiency by using special non-portable constructs, but we are talking
a completely different environment here when we talk about using C as
a kind of low level pseudo machine language for compiler output.