C to Forth Tranlator? 
Author Message
 C to Forth Tranlator?



Quote:

>>use the Forth-based facility very often).  Is there a
>>program out there which would allow them to write C code
>>(perhaps with restrictions) and translate it to Forth?

>    It would be simple to let Forth be the OS for your project
>and let it compile and run your client's C code directly.  No real
>reason to need to translate C to Forth that I can see.

>    If you need backup for this idea, I think that the new
>Sun computers are set up this way.

    I think you have missunderstood the Open Boot PROM on Sun
computers. Every computer needs at least a small amount of
machine code somewhere to get it started, initalize its I/O
chips, read the disk or look for data from the network, etc.
Sun Sparc computers do not use Forth as an OS. Their boot ROM is
written in Forth. They normally start up, test their memory,
and then read the Unix operating system (written in C and  
assembly) from a hard disk or a network. All the Forth code
is disconnected once Unix starts to run. You can interrupt
the boot process and use the Forth system if you like, and
if the machine has a major crash you can try to find out why
using Forth since the boot PROM will be enabled.

    As for the original question, it would not be simple to
translate C into Forth. There was an attempt at such a thing
years ago by Harris Semiconductor when they were making a
CPU that executed Forth directly. But the project was cancelled
before the C to Forth compilier was working well enough.

    I don't think there is any easy way to translate C code
or convert C programmers to Forth. The reason Forth works
so well is that it does things completely differently from
C. You should convince the C programmers that they will have
to learn everything all over again. Perhaps you can tell them
that Forth is a vastly improved assembly language de{*filter*}
to put them in the right state of mind. People seem to be more
willing to learn to use a new de{*filter*} than they are to learn a
new language (or editor).

--



Mon, 12 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:
Nicholas Sterling  writes:
> I've got a situation where Forth seems like the appropriate
> language to use (compactness, speed, et. al.), but a user
> community that is reluctant to learn Forth (they would not
> use the Forth-based facility very often).  Is there a
> program out there which would allow them to write C code
> (perhaps with restrictions) and translate it to Forth?

Several C to Forth translators have been discussed, and I am
sure various ones are in the literature. Otherwise Anton
Ertl's program Gray (or Grey?)--a generalized table-driven parser
generator--could be used to devise you own.

HOWEVER...

While I could care less about C, I once wanted a simple means to
translate the huge fortran subroutine libraries to Forth. So I
wrote a small program that translated about 90-95% of typical
FORTRAN programs. It handled DO loops with step-sizes and all,
structured IF..THEN...ELSE...ELSIF...ENDIFs, and formulas;
but not GOTO's, arithmetic IF's, EQUIVALENCE, inline functions or
any of the other obsolescent stuff left over from FORTRAN I.
The FORmula TRANslator part I use a lot, but not to translate
FORTRAN programs. It is included on the code disk that comes
with my book. But I did not release (nor do I intend to) the
code to handle DO's and IF's.

The problem was that good FORTRAN does not translate to good Forth.
The best of the resulting code was slow, cumbersome, in a word,
mediocre. I eventually concluded it was better to translate by hand.

I fear the result would be the same with C -> Forth; the audience
would look at the emitted code and say "Ecchh!" and they would be
right. Certainly I do not see this as a way to either learn or
appreciate Forth.

--
Julian V. Noble



Mon, 12 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:

>use the Forth-based facility very often).  Is there a
>program out there which would allow them to write C code
>(perhaps with restrictions) and translate it to Forth?

        It would be simple to let Forth be the OS for your project
and let it compile and run your client's C code directly.  No real
reason to need to translate C to Forth that I can see.

        If you need backup for this idea, I think that the new
Sun computers are set up this way.

Jim



Mon, 12 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:

>    As for the original question, it would not be simple to
>translate C into Forth. There was an attempt at such a thing
>years ago by Harris Semiconductor when they were making a
>CPU that executed Forth directly. But the project was cancelled
>before the C to Forth compilier was working well enough.

The Harris machine didn't really "execute Forth directly." It
was a two-hardware-stack machine with a stack-oriented instruction  
set. Stack machines have existed for many years (dating back to
the old Burroughs CPUs at least) and have been targeted efficiently
by every type of high level language compiler. The main features
of the Harris CPU (and the Novix CPU) that made it a good target
for a Forth compiler were the two hardware stacks and the very
efficient call/return mechanism. Even so, writing a Forth
compiler that generated maximally efficient code for
the Harris CPU was a non-trivial exercise. Aside from that, the
C compiler for the Harris chip worked well enough. I saw it
demonstrated with a full symbolic debugging environment at least
2 years before Harris gave up on the RTX product. The reasons
why the C compiler/de{*filter*} environment never reached market
are still obscure (at least to me) but I surmise they related
to Tom Hand and internal political/marketing/technical confusion
at Harris, not to any intrinsic problem with the C product.

Ray Duncan



Tue, 13 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?


Quote:
> I've got a situation where Forth seems like the appropriate
> language to use (compactness, speed, et. al.), but a user
> community that is reluctant to learn Forth (they would not
> use the Forth-based facility very often).  Is there a
> program out there which would allow them to write C code
> (perhaps with restrictions) and translate it to Forth?

Although not strictly an answer to your question, I understand that the GNU
C compiler uses a machine independant stack oriented language as an
intermediate step in the code generation process ... perhaps that might be
a starting point (at least you'd get a parse tree out of the deal).

rss.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Sciuk    Director, Technical Services,                   (905) 529-8117
Innovus Inc.    204-200 James St S. Hamilton, Ont. Can. L8P 3A9 VMail: ext 203



Tue, 13 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

|> Nicholas Sterling  writes:
|> > I've got a situation where Forth seems like the appropriate
|> > language to use (compactness, speed, et. al.), but a user
|> > community that is reluctant to learn Forth (they would not
|> > use the Forth-based facility very often).  Is there a
|> > program out there which would allow them to write C code
|> > (perhaps with restrictions) and translate it to Forth?

You won't get a speedup in execution time by using a
Forth-to-C-translator and any current Forth implementation instead of
a good C compiler. I doubtful that you will get more compact code. You
may get a speedup in the edit-compile-run cycle, however.

If Forth code is faster and more compact, it's due to the way that
Forth programmers write code, not due to the language
implementation. For a recent paper
(http://www.complang.tuwien.ac.at/papers/ertl&maierhofer95.ps.gz), we
translated some Forth code to C code and used an optimizing compiler
on that. The resulting machine code was faster than any other Forth
implementation and more compact than the intermediate code of a 32-bit
indirect threaded code system.

|> Several C to Forth translators have been discussed, and I am
|> sure various ones are in the literature. Otherwise Anton
|> Ertl's program Gray (or Grey?)--a generalized table-driven parser
|> generator--could be used to devise you own.

Gray is a parser generator, but it produces recursive-descent parsers,
not table-driven parsers. It has been used to implement a Pascal
subset. Marcel Hendrix used it to implement a Pascal-like language.
It would be a good choice for implementing a compiler that compiles to
Forth, because you can use it to compile to *executable* Forth code,
without the overhead of intermediate Forth source. You can find it at
http://www.complang.tuwien.ac.at/forth/gray4.tar.gz (or gray4.zip).

Rob Scuik has suggested using GCC. I'd rather suggest LCC (if you want
a translator written in C). There is even a backend for a stack-based
interpreter, discribed in a paper by Todd Proebsting in the POPL'95
proceedings. GCC's back end is designed for register machines, it
won't help much, so you can just as well use the simpler LCC.

  author =       "Todd A. Proebsting",
  title =        "Optimizing an ANSI C Interpreter with Superoperators",
  crossref =     "popl95",
  pages =        "322--332"

Quote:
}


  booktitle =    "Principles of Programming Languages (POPL '95)",
  title =        "Principles of Programming Languages (POPL '95)",
  year =         "1995",
  key =          "POPL '95"

Quote:
}

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html


Tue, 13 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:
> Gray is a parser generator, but it produces recursive-descent parsers,
> not table-driven parsers. It has been used to implement a Pascal
> subset. Marcel Hendrix used it to implement a Pascal-like language.

This is sample code in the PL/1 language that is correctly translated
to Forth by a Gray-generated parser. Gray is really something. Check it
out when you get tired of Life.

The generated code uses lots of variables, values and (f)locals, but is
still almost as fast as the underlying Forth (iForth). In practice
this means it beats the Borland Pascal 7.0 compiler re execution speed
(especially for floating-point code). It does *not* beat (Turbo) C.

I do not show the generated Forth code for fear of long-windedness,
but if somebody is curious: just ask.

-marcel

-- -------------------------------------------------------------------
   (* From N. Wirth's book Compilerbau. - Stuttgart: Teubner, 1986 *)

ANEW PL/1

PROGRAM ebnf;

CONST
  empty = ' ';
  ESC = '!';

VAR
  sym       : CHAR;
  source    : STRING;
  next,last : INTEGER;

PROCEDURE fetchsym;
BEGIN
  IF next > last THEN
     READLN(source); next:=1; last:=source[0]
  END;
  sym:=source[next]; INC(next)
END;

PROCEDURE getsym;
BEGIN
  REPEAT
    fetchsym; WRITE(sym)
  UNTIL (sym <> empty) OR (sym = ESC)
END; { GetSym }

PROCEDURE error;
BEGIN
  WRITELN; WRITE('Syntax incorrect [',sym,'].');
  halt(1)
END; { error }

FORWARD expression;

PROCEDURE factor;
BEGIN
  CASE sym OF
    'A'..'Z': getsym { non-terminal symbol }
    |  '"'  : getsym; getsym; IF sym = '"' THEN getsym ELSE error END
    |  '('  : getsym; expression; IF sym = ')' THEN getsym ELSE error END
    |  '['  : getsym; expression; IF sym = ']' THEN getsym ELSE error END
    |  '{'  : getsym; expression; IF sym = '}' THEN getsym ELSE error END
   ELSE error
   END
END; { factor }

PROCEDURE term;
BEGIN factor; CASE sym OF 'A'..'Z', '"', '(', '[', '{' : factor END END;

PROCEDURE expression;
BEGIN term; WHILE sym = '|' DO getsym; term END  END;

BEGIN { main }
 WRITELN('enter something in EBNF-form for processing.');
 last:=1; next:=2;
 getsym;
 WHILE ((sym <> '.') AND (next <= last)) DO
     CASE sym OF 'A'..'Z' : getsym ELSE error END;
     CASE sym OF   '='    : getsym ELSE error END;
     expression;
     IF sym = '.' THEN
        WRITELN; WRITE('End of source, enter ''!'''); getsym  
     ELSE error
     END
 END
END.

(*
 Example:     A="x" | ( B ).
 (Personnally I think EBNF has a bug. You should be able to enter
  A="x" | "(" B ")".).
*)



Wed, 14 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:

> The Harris machine didn't really "execute Forth directly." It
> was a two-hardware-stack machine with a stack-oriented instruction  
> set. Stack machines have existed for many years (dating back to
> the old Burroughs CPUs at least) and have been targeted efficiently
> by every type of high level language compiler.

I think this is a very fertile comment, although at first it seemed
to me like an attempt at defining "executing Forth directly" in a
rather narrow way (sure the Novix CPU didn't execute Fig-Forth or
Forth-83 or ANSI Forth directly, but its machine language certainly
made me feel that it was designed to execute elementary Forth
instrunctions in silicon, so that I did in fact feel that it
was "executing Forth directly").

This is fertile I think because
 -- it underlines that some of us think of Forth as a language
  that has been standardized for the benefit of the Forth community
  and to facilitate development of commercial implementations of
  the language, whereas some of us think of Forth as a fluid set of
  ideas that is powerful and adaptable precisely because it is a
  dynamic process in which we are refining and improving stack
  architectures (is Forth a language, or is it a Minimal Instruction
  Set Computer, i.e. is Forth about syntax or is it about computer
  architecture?).
 -- it is interesting to compare Forth with related stack machines
  so that it appears as a fundamental research program rather than as
  a commercial product, i.e. the goals are different.

The question always arises as to how one finances any "movement" or
activism such as the Forth community.  Surely producing commercial
compilers and selling consultant services are only two such methods
of financing something that we want to do in any case.

E.g., Ray Duncan has been able to write books such as _Extending DOS_
that reflect the insight that a Forth enthusiast can get into the
surrounding operating system and hardware, and the faster learning
cycle that Forth yields.

In strategic terms, what counts is the inimitable unique path of
development, placed in a personal and distributional network in such
a way that tempo of development (of both code and knowledge) is
at a maximum.  If the code and knowledge relate to e.g. stack-oriented
machine architectures rather than ANSI standards, then perhaps we
should be trying to exploit that angle, since we are expert in that
area.




Wed, 14 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?
Thus spake Julian V. Noble:

{discussing a Fortran-to-Forth translator}

Quote:
>The problem was that good FORTRAN does not translate to good Forth.
>The best of the resulting code was slow, cumbersome, in a word,
>mediocre. I eventually concluded it was better to translate by hand.

>I fear the result would be the same with C -> Forth; the audience
>would look at the emitted code and say "Ecchh!" and they would be
>right. Certainly I do not see this as a way to either learn or
>appreciate Forth.

Yeah, but...

What about those gobs of C programs out there?  Once in a while, one
might turn out to be useful enough to want to use... and hang what
the code looks like, maybe I'd get to that later.

Oh well, one can always hope.  If I had the expertise, I'd take a
swing at writing a translator myself....

Now that I'm think about this, I seem to remember a Pascal-to-Forth
translator out there -- maybe it would be a start?
--
Larry Kollar, Dawsonville GA  | *** Hatred is {*filter*} *** (1 Jn 3:15)



Thu, 15 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?
|> Thus spake Julian V. Noble:

[dissmissal of C->Forth translators]

|> Yeah, but...
|>
|> What about those gobs of C programs out there?

Use a conventional C compiler for them. If you are talking about C
libraries that you want to call from Forth, some Forths can call
functions in other languages, and IMO that's the right approach to
this problem.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Fri, 16 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

)Although not strictly an answer to your question, I understand that the GNU
)C compiler uses a machine independant stack oriented language as an
)intermediate step in the code generation process ... perhaps that might be
)a starting point (at least you'd get a parse tree out of the deal).

It uses a tree based RTL description based around registers (an unlimitted
number of them allocated *every* time a new value is created) Later
on most of them are eliminated leaving most routines with <50 'registers',
which are then mapped to real storage. This is one of the reasons gcc
generates much better code for RISC designs with large register files than
intel machines.

If theres a stack description in there I did not see it last time I hacked
the compiler source...

--
Paul Shirley: too lazy for a sig.



Fri, 16 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:

>Yeah, but...

>What about those gobs of C programs out there?  Once in a while, one
>might turn out to be useful enough to want to use... and hang what
>the code looks like, maybe I'd get to that later.

Our approach is just to develop a good "bridge" to enable polyFORTH
programs to call C programs.  Starting as a very simple bridge, it has
been enhanced in the past year such that the current version included in
our protected-mode polyFORTH can call major C libraries.  I gave a paper
on it at the Rochester conf. this year (copies on request).

It isn't necessary to translate good Forth to bad C to use these
programs!



Fri, 16 Jan 1998 03:00:00 GMT  
 C to Forth Tranlator?

Quote:


>)Although not strictly an answer to your question, I understand that the GNU
>)C compiler uses a machine independant stack oriented language as an
>)intermediate step in the code generation process ... perhaps that might be
>)a starting point (at least you'd get a parse tree out of the deal).
>It uses a tree based RTL description based around registers (an unlimitted
>number of them allocated *every* time a new value is created) Later
>on most of them are eliminated leaving most routines with <50 'registers',
>which are then mapped to real storage. This is one of the reasons gcc
>generates much better code for RISC designs with large register files than
>intel machines.
>If theres a stack description in there I did not see it last time I hacked
>the compiler source...

In a talk that Phil Koopman gave once upon a time, he mentioned that he had
worked on a Stack back-end for Gnu C as part of the C compiler work he had
done for the Harris RTX.  All he could say about that work was it wasn't
easy to cleanly convert register-transfers into stack-transfers, and that no,
the code was neither completed nor available.



Sat, 17 Jan 1998 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. C to Forth Tranlator?

2. to CS: or not to CS: in F-PC assembler

3. CS people in Forth?

4. CS People in Forth?

5. Forth in CS

6. Believe or not, Forth in CS!

7. Forth and CS

8. Where does FORTH belong in CS and Academia?

9. What's Forth good for...Was: CS people in Forth?

10. Getting Forth related files (was: Forth primer/teaching Forth)

11. Forth in Forth vs. Forth in assembly language

12. Forth in Forth vs Forth in assembly

 

 
Powered by phpBB® Forum Software