This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

new front-end: ksi + few questions


Hello,

I'm writing a new front-end for GCC. My goal is to provide very
simple language, suitable as a target for some other compiler,
machine-independent assembler. The language itself is more or less
textual representation of syntax trees generated by all front-ends.

Of course somebody might ask why not use tree interface directly?
Hmmm... I'm writing ksi compiler since a week or so. I will spent
few next weeks/months testing it and adding some neat features. 
This is time you won't have to spent :)

Also interfacing trees from, let's say SML, or OCAML can be hard.

Lexical structure of lanuage is verysimple, reasembling mixture
of C (string constants, comments (// was choosen, so we are able
to use cpp, if there are any good reasons to do so)) and Lisp.

Here is an example:

---CUT---
!version 0

[unit
// int excl(int x)
// {
//   if (x == 0)
//     return 1;
//   else
//     return x * excl(x - 1);
// }
  (func public (type int 32) excl
    (parm (var (type int 32) x) (nil))
    (bind (cond (bin eq (ref x) (const (type int 32) 0))
      (return (modify (result) (const (type int 32) 1)))
      (return (modify (result) 
        (bin mult (ref x) (call excl [parm 
          (bin minus (ref x) (const (type int 32) 1))])))))))

// extern int printf(void *, ...);
  (func extern (type int 32) printf 
    (parm (var (type ptr) str) (elipsis)) (nil))

// int main(void)
// {
//   printf("%d\n", excl(5));
//   return 0;
// }
  (func public (type int 32) main (nil)
    (bind [compound
      (call printf [parm 
        (const (type ptr) "5! = %d\n") 
	(call excl (parm (const (type int 32) 5) (nil)))])
      (return (modify (result) (const (type int 32) 0)))]))
]
---CUT---

After running xgcc on this, and running a.out we'll see 5! = 120.

As you can see there are many (), and the language is quite verbose.
However it is not meant to be written by humans. And as you probably
know duming tree generated for code in this form is easy. Also it is
quite easy to parse, I havn't used lex nor yacc.

As of now most useful nodes from tree.def are implemented, not
well tested though.

Front end is available at ftp://aleph-0.dhs.org/pub/ksi/ and
(shortly) at ftp://ftp.pld.org.pl/people/malekith/ksi/ is somebody
wants to look at it. It was tested against gcc-3.0.1 release and
current CVS snapshot.

But let's get to the point, as annoucing ksi is not the reason of
writing this letter :) I use build*() functions to build the tree,
then, once per function, I pass the result to expand_expr() function.
I don't know if this functional in concept way is the best, but I like 
it. Anyway, I would like to have (goto ...) and (label ...) terms.
{LABEL,GOTO}_EXPR seems to be OK for this. However I havn't seen
any actuall usage of them in GCC sources, and expand_expr() hasn't
got a rule for LABEL_EXPR. I wonder if "case LABEL_EXPR: 
expand_label(TREE_OPERAND(exp, 0)); return const0_rtx;" hasn't been
added intentionally or by accident? Anyway, after adding it in
lang_expand_expr() it seems to work fine, however I hasn't extensivly
test it, so maybe there is something more to do then expand_label()...

And the second question: is return value in EXIT_BLOCK_EXPR is going
to get implemented? I have added support for it in ksi, and was
rather supprised with sorry() :)

Third question: can I assign DECL_RESULT(), do some things
(lot of things...) and then expand RETURN_EXPR()? Or the
value (stored in register) will be destroyed by "lot of things",
so it is only safe to use DECL_RESULT() in RETURN_EXPR()
0th operand?

Fourth: can gabage collection occur only at ggc_collect() call
or also at ggc_alloc()? From comments in code and code itself
it seems that only at ggc_collect(), but cobolforgcc manual
(Chapter 14, about GCC internal tree represenatation and
writing own GCC front-end, very halpful thing) states the other way.
As I know the current state, my question is more like: 'is it going
to change' ?

And the last question: what are the conditions for including front-end in
gcc CVS and official releases?  Especially can the code require GCC, has
it to be K&R and indented the GNU way?  It seems that front-ends other
then C are compiled in second stage with freshly built gcc.  I guess
it has to be licensed under GPL :) I would like to obtain localised CVS
write access, who to send ssh key?

Best Regards
-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:                                  |                : {b,e>+}++ !tv h
: Current project:  http://aleph-0.dhs.org/ywindow/ : PLD Team member


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]