public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michal Moskal <malekith@pld.org.pl>
To: gcc@gcc.gnu.org
Subject: new front-end: ksi + few questions
Date: Mon, 10 Sep 2001 05:23:00 -0000	[thread overview]
Message-ID: <20010910143546.A23227@aleph-0.aleph-0.dhs.org> (raw)

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

             reply	other threads:[~2001-09-10  5:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-10  5:23 Michal Moskal [this message]
2001-09-18 22:23 ` Fergus Henderson
2001-09-19  4:19   ` Michal Moskal
     [not found] <200109220207.WAA13165@cr681416-a.ktchnr1.on.wave.home.com>
2001-09-23  4:36 ` Fergus Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010910143546.A23227@aleph-0.aleph-0.dhs.org \
    --to=malekith@pld.org.pl \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).