Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!cpsc6a!rtech!wrs!dg
From: dg@wrs.UUCP
Newsgroups: comp.lang.c
Subject: Re: Register Transfer Language
Message-ID: <295@wrs.UUCP>
Date: Wed, 12-Aug-87 16:48:45 EDT
Article-I.D.: wrs.295
Posted: Wed Aug 12 16:48:45 1987
Date-Received: Sun, 16-Aug-87 09:22:27 EDT
References: <8740@brl-adm.ARPA>
Reply-To: dg@wrs.UUCP (David Goodenough)
Organization: Wind River Systems, Emeryville, CA
Lines: 49

In article <8740@brl-adm.ARPA> ADLER1%BRANDEIS.BITNET@WISCVM.WISC.EDU writes:
> .....
>
>Apparently, the compiler works by translating (or compiling ?) C code
>into the intermediate language RTL (which is contained in the compiler
>source code) and then compiles (?) the resulting RTL
>code. RTL is close enough to a general purpose machine language that
>one achieves portability merely by giving RTL a file containing a
>machine description to pin down specifics. The description of the
>features of RTL in internals-2 is nice to read, but I can't help feeling
>that since RTL is a general language and since it plays such a key role
>in the GNU C Compiler, that it might be instructive to invest some time
>in studying RTL in its own right.
>
>My question is this: how can one isolate the language RTL from the GNU
>C Compiler so that one can write and run programs in it?

I don't know the workings of the GNU C compiler, but it may be the case
that the RTL file is produced and saved albeit as a temporary file.
If the passes are available as separate programs (e.g. like cpp / ccom / c2
with BSD UNIX) then it may be possible to isolate the bits you are after
in this manner. While on this subject, several other languages have taken
a similar approach, notably UCSD Pascal with it's P codes, and BCPL with
O code files. In this instance BCPL is probably more appropriate, as the
idea was to write ONE ONLY compiler that went from BCPL source to O codes,
then for each machine write an O code compiler to produce native executables.
Porting then was trivial: generate the O codes for the front end (BCPL -> O
code) on a working implementation, send them over to the new machine,
run them through the back end, and you have your working compiler, at a
VERY minimal cost. This is an subset of the N machines / M languages
problem, but since porting BCPL is so easy (and it is - it took a team
of three of us about a month to write the O code to executable program
for an apple w/ a 6502, hence we had BCPL running on an apple in a month)
it demonstrates the advantages of working with a RTL type of setup.
Alternatively, as has been mentioned, if you produce hardware that directly
executes Pascal P codes (I've seen it done with AMD 2900 bit slices) or
BCPL O codes, you can get an implementation of the language that goes
faster than the new transwarp ships in Star Trek - the bit slice P code
machine I saw was faster than current 12MHz 68020 technology, and that
was just a 16 bit setup running at a leisurly 2 MHz.
Hopefully this provides some insight into some of the advantages of
separating RTL out, if you can do it you will be doing the world a favour!!
--
		dg@wrs.UUCP - David Goodenough

					+---+
					| +-+-+
					+-+-+ |
					  +---+