Re: What a translation unit is.

From: ellie fant (pcrcutitout1000011_at_uko2.co.uk)
Date: 11/30/03 

Date: Sun, 30 Nov 2003 07:50:23 -0000

"Greg Comeau" <comeau@panix.com> wrote in message
news:bqc4kk$cgi$1@panix3.panix.com...
> In article <1070161752.416886@news.minx.net.uk>,
> ellie fant <pcrcutitout1000011@uko2.co.uk> wrote:
> >"Greg Comeau" <comeau@panix.com> wrote in message
> >news:bqbddl$s1c$1@panix2.panix.com...
> >> I'm going to talk a slightly different approach to the messages
> >> I've skimmed in this thread so far. Let's assume it is correct
> >> that "translation unit" can both be the input and output of the
> >> compiler. IOWs, for one, a translation unit goes into the
> >> compiler proper (in some way). And for another, in some way,
> >> a translated translation unit come out of the compiler proper.
> >> This therefore means that a translated translation unit is a
> >> translation unit. The point I want to make is that even if
> >> this is true, it is unhelpful.
> >
> >A tranlation unit is a unit( some modular entity ) that translates one
> >format of code to another.
>
> In this post you make it clear that you are not talking about a
> translation unit as an input/output, but an "activity", perhaps akin
> to say a central processing unit. The standard does not take this
> view, and so I'm now wondering if we're all not talking past each other,
> and hence the disagreement? OTOH, I don't think you termed it
> this way in your other posts.
>
> >So therefore it only makes sense to me that the most usefull translation
> >units that concern us are object files and source code files unless you
are
> >writing your own compiler.
>
> Certainly object files usually concern many people.
>
> >As source files are generally called source files and it is clear what
one
> >means by this,
>
> Usually.
>
> >this only leaves compiler output/linker input. This may not
> >necessarily be an object file
>
> That's why I've say usually above, and in other posts.
> But let's keep assuming the traditional compiler system.
>
> >and therefore it is easier to say TU than to
> >say an object file or an object-code library or whatever.
>
> I disagree. So let's just disagree.
>
> > > I make this assertion because
> >> this would indicate that the same type of file goes in and out,
> >> and of course, this is not so.
> >
> >Well no because a TU by definition outputs something different from what
is
> >put in.
>
> Often. (note I'm using Standard C and C++'s definition)
>
> >> So if this terminology is correct,
> >> it sure is confusing.
> >
> >I don't find it confusing in the slightest.
> >There are 3 main phases of translation that concern the average
programmer.
> >1) preprocess
> >2) compile
> >3) link
>
> Something like this.
>
> >The only thing that I find confusing is why people say that stage 3 is
not a
> >phase of translation.
> >:-)
>
> I haven't seen this said in this thread yet. What they are saying
> is that the C or C++ don't refer to those outputs as TUs.
>
> > > I realize that may be nothing new do to
> >> the complexities of various languages and of compilation,
> >> but the redundancy seems weak. I very much like that a
> >> preprocessed preprocessing translation unit is a translation unit
> >> and that a translation unit that has been compiled is object code.
> >
> >Now that is confusing... prepropessed preprocessing translation unit.
> >:-s
>
> Yep, it's confusing. Luckily the average programmer
> is not normally concerned with this nitty gritty part,
> and so few would even know this.
>
> >> Otherwise, we might as well be saying that source code is object
> >> code. But I know when I teach students, that they would have
> >> my *** tossed out for saying such things to them. So I find
> >> the distinguishment significant and helpful. I find this so
> >> both with talking standardese, and I find this so when plain
> >> old trying to discuss it. Even so when acknowledging that
> >> the translator may not be a traditional compiler system.
> >> --
> >
> >It is probably a more suitable term for the piece of software
> >that does the translating.
>
> This seems to verify my comment above about central processing unit.
> Yes, we could argue this, but it's not the position the standards take.
>
>
> >However if you think of the term as meaning a physical file that is
> >something inbetween states of tranlation then the object file is most
suited
> >to the term .
>
> At least for transitional systems. But that's why it's good that
> the standard does not use the term object file.
>
> >Look at the picture:
> >Source file >>>>>> Executable.
> >The source file is a unit to be translated. And the executable is the
> >tranlated unit.
>
> I know what you're saying, but it's not the words normally used for
> C and C++. They use phrases such as "program image" and
> "complete C[++] program" for executable.
>
> >The first bit that comes inbetween is the object file so you have:
> >Source file >>>>>> object file >>>>> Executable.
> >
> >Then if you want to go into in more detail and get into the workingins of
> >the compiler:
> >Source file >>>>(compiler)>>>>object file>>>>(linker)>>>> Executable.
> >
> >BTW: The compiler and the linker are the real TU's IMO but this is
obviously
> >not what is meant..
>
> Yes, now you're agreeing with us!
>
> >If you want to discuss the inner workings of the compiler then you have
to
> >drop into a different scope.
> >using Compiler scope;
> >source file >>> preprocessor >>> compiler >>> object file.
>
> Personally I consider it similarly, but let's not split hairs
> on this point.
>
> >The compiler will be different in each case but we can understand that
the
> >compiler creates some kind of TU after preprocessing and before compiling
> >but now we have dropped into a different scope and it's irrellevant so
lets
> >get out of here and go back to the big picture.
> >not using compiler scope anymore;
> >
> >Pheww that's better I was getting claustrophobia in there.
> >So lets get back to the phases of translation.
> >Source file (unit to be translated) >>> Executable ( unit after
> >translation).
> >then:
> >Source file >>> object file (partially translated unit)>> executable.
> >
> >So we have
> >Source file goes into the compiler.
> >Object file emerges
> >Object file goes into the linker
> >Executable emerges.
>
> Again, I don't prefer the distinguishment, but ok (I think),
> since in the end, everybody agrees with the last 4 lines,
> in a system of that kind.

What do you mean by I don't prefer the distinguishment?
>
> >Now if you want to zoom in on the part where the source file goes into
the
> >compiler and ignore the rest of the translation process then be my guest.
>
> I'm not doing that.
Well join the club that makes two of us.

>
> >But that is not the point here, the point is that if you want to talk
> >portability then the last thing you want to do is narrow your scope and
the
> >first thing you have to do is look at the big picture. They can't have it
> >all ways.
>
> I wasn't referring to portability either, and don't believe others
> were either... we were just discussing things more generally with
> a slant to the traditional compiler.
> --
No but the argument stems from a seperate arugment about portability

Quantcast