heh-heh, pardon the inlfammatory subject, but you know me.
Just started working on a C to Lisp translator, using Antlr. This is
detectibly more fun than translating from C to Lisp by hand. (I have a C
app to translate. It had been translated (most of it) to Java long ago,
but looking at that code I can see that (a) Java sucks and (b) it sucks
in ways that badly damaged the code, the screaming issue being "no
preprocessor". So no interest anymore in Java-to-CL.
Anyone else want to play? As Edi can tell you, I do not read doc very
well, but I think Antlr will force my hand on that.
Or know a better way than Antlr? gcc_xml does not do function bodies.
Bzzt. Interestingly, I am cannabilizing a GnuCEmitter working off a
parser that does not look at the headers. That has caused surprisingly
few problems, some of which I will be able to solve by teaching the GnuC
Parser about some of my more diabolical C macros.
kenny
Did you consider adapting my C++ -> Scheme compiler?
The version on my web site is probably a bit out of date,
so email me if you want to play with the latest version.
"Kenny Tilton" <·············@nyc.rr.com> wrote
>
> Just started working on a C to Lisp translator, using Antlr.
[...]
> Or know a better way than Antlr? gcc_xml does not do function bodies.
Do it in Lisp. Juliusz Chroboczek has written cl-yacc and a C parser in Lisp just for
that:
Juliusz Chroboczek wrote:
>Well, I wrote CL-Yacc exactly for that reason -- I needed to parse C.
>I've ripped out the lexer, parser and pretty-printer from my current
>development sources and put them on
>
> http://www.pps.jussieu.fr/~jch/software/files/cpc-parser-20050411.tar.gz
That link does not work anymore but you can ask Juliusz Chroboczek for a recent version.
(IIRC I have a copy somewhere)
>You are welcome to use this code in any way you see fit. I would
>appreciate it, however, if you could make sure to credit me as the
>original author in the documentation of any software that uses these
>sources.
>
>And Steven H. is right -- parsing C is a pain.
>
>This is most definitely work in progress; while a variant of this code
>has successfully parsed a few thousands lines of C, it is known to be
>incomplete and buggy. Of course, I'm interested in any fixes you may
>want to send me.
Marc
In article <······················@giganews.com>,
Marc Battyani <·············@fractalconcept.com> wrote:
> Juliusz Chroboczek wrote:
> >Well, I wrote CL-Yacc exactly for that reason -- I needed to parse C.
> >I've ripped out the lexer, parser and pretty-printer from my current
> >development sources and put them on
> >
> > http://www.pps.jussieu.fr/~jch/software/files/cpc-parser-20050411.tar.gz
>
> That link does not work anymore but you can ask Juliusz Chroboczek for a
> recent version.
> (IIRC I have a copy somewhere)
It's available from:
:; darcs get http://www.pps.jussieu.fr/~jch/software/repos/cpc
Ironically, I've also started working on a C parser (using CL-YACC!)
before I saw this. I'll probably continue mine just for the experience.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Just interesting, how do you deal with the following issues?
- fixnums usually cannot represent full 32-bit numbers, so bignums
will be used instead in many cases (very ineffective);
- pointer arithmetic, mixing pointer<->arrays, pointer<->uint conversion;
- malloc() / free() memory management;
... probably many other things like these ...
?
Ivan Shvedunov wrote:
> Just interesting, how do you deal with the following issues?
> - fixnums usually cannot represent full 32-bit numbers, so bignums will
> be used instead in many cases (very ineffective);
Is this a translation issue or just "C will be faster in any application
where 32-bit numbers tend to reach the limit of fixnums"?
> - pointer arithmetic, mixing pointer<->arrays, pointer<->uint conversion;
> - malloc() / free() memory management;
> ... probably many other things like these ...
My subject was indeed in jest. I just want to get the bulk of 23kloc of
C reasonably "re-typed" as CL, so foo(x,y,z); becomes (foo x y z)
without pushing my carpal tunnel syndrome over the edge.
I am still open to the possibility of failing completely in the face of
C syntax silliness. Even found a confession in K&R that their treating
typedef as a storage class specifier in the grammar is a joke. <sigh> Am
I the only one who takes programming seriously?!
kt
In article <·····················@news-wrt-01.rdc-nyc.rr.com>,
Kenny Tilton <·············@nyc.rr.com> wrote:
> My subject was indeed in jest. I just want to get the bulk of 23kloc of
> C reasonably "re-typed" as CL, so foo(x,y,z); becomes (foo x y z)
> without pushing my carpal tunnel syndrome over the edge.
If this is what you want the parser I'm working on already produces
mostly lispish-looking code for function bodies - where it really falls
down on right now is declarations, as they are so screwy in C.
For example (declarations replaced with ... for brevity):
long sys_times(struct tms * tbuf)
{
if (tbuf) {
struct tms tmp;
struct task_struct *tsk = current;
struct task_struct *t;
int utime, stime, cutime, cstime;
read_lock(&tasklist_lock);
utime = tsk->signal->utime;
stime = tsk->signal->stime;
t = tsk;
do {
utime = cputime_add(utime, t->utime);
stime = cputime_add(stime, t->stime);
t = next_thread(t);
} while (t != tsk);
spin_lock_irq(&tsk->sighand->siglock);
cutime = tsk->signal->cutime;
cstime = tsk->signal->cstime;
spin_unlock_irq(&tsk->sighand->siglock);
read_unlock(&tasklist_lock);
tmp.tms_utime = cputime_to_clock_t(utime);
tmp.tms_stime = cputime_to_clock_t(stime);
tmp.tms_cutime = cputime_to_clock_t(cutime);
tmp.tms_cstime = cputime_to_clock_t(cstime);
if (copy_to_user(tbuf, &tmp, sizeof(struct tms)))
return -EFAULT;
}
return (long) jiffies_64_to_clock_t(get_jiffies_64());
}
((DEFUN (...)
(PROGN
(IF tbuf
(LET (...)
(read_lock (REF tasklist_lock))
(SETF utime (ELT-> (ELT-> tsk signal) utime))
(SETF stime (ELT-> (ELT-> tsk signal) stime))
(SETF t tsk)
(DO-WHILE
(PROGN
(SETF utime (cputime_add utime (ELT-> t utime)))
(SETF stime (cputime_add stime (ELT-> t stime)))
(SETF t (next_thread t)))
(!= t tsk))
(spin_lock_irq
(REF (ELT-> (ELT-> tsk sighand) siglock)))
(SETF cutime (ELT-> (ELT-> tsk signal) cutime))
(SETF cstime (ELT-> (ELT-> tsk signal) cstime))
(spin_unlock_irq
(REF (ELT-> (ELT-> tsk sighand) siglock)))
(read_unlock (REF tasklist_lock))
(SETF (ELT. tmp tms_utime) (cputime_to_clock_t utime))
(SETF (ELT. tmp tms_stime) (cputime_to_clock_t stime))
(SETF (ELT. tmp tms_cutime) (cputime_to_clock_t cutime))
(SETF (ELT. tmp tms_cstime) (cputime_to_clock_t cstime))
(IF (copy_to_user
tbuf
(REF tmp)
(SIZEOF-TYPE ((STRUCT tms))))
(RETURN (- EFAULT)))))
(RETURN (CAST
(jiffies_64_to_clock_t (get_jiffies_64))
(long))))))
Still a lot of work to do to understand declarations usefully...
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
On 2005-12-31 00:23:31 +0000, Kenny Tilton <·············@nyc.rr.com> said:
> Am I the only one who takes programming seriously?!
Possibly.
Some do it for thr money (like in any other branch: a *good*
doctor is as rare as a good programmer)
Some do it because their mother told them to
A few of us to it for fun.
How could you be serious when you're lauging all day long? :-)
--
JFB
Kenny Tilton <·············@nyc.rr.com> writes:
> Or know a better way than Antlr? gcc_xml does not do function
I prefer ANTLR/PCCTS over yacc/lex if I'm working in C/Java. I like
Zebu when working in CL (even though I wish it had a lexical
analyzer). But I guess you will not find a ready Zebu C grammar
specification out there?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad wrote:
> Kenny Tilton <·············@nyc.rr.com> writes:
>
>> Or know a better way than Antlr? gcc_xml does not do function
>
> I prefer ANTLR/PCCTS over yacc/lex if I'm working in C/Java. I like
> Zebu when working in CL (even though I wish it had a lexical
> analyzer). But I guess you will not find a ready Zebu C grammar
> specification out there?
>
> Petter
>
I used Zebu on a project a few years ago and I'm quite relieved that Craig
Lanning finally re-wrote that part of our system in lisp. Parsers built on
that LALR crap / jump tables are difficult to debug. Back in those days I
used ANTLR to debug the grammar we were developing, but even there I would
have been better off with lisp. What's wrong with using the lisp reader for
the lexer? Craig wrote a nice one for our project. The code can be found
here: http://cvs.sourceforge.net/viewcvs.py/exp-engine/expresso/p11/
(see reader.lsp, token-stream.lsp)
The code generation part of that work could be better (It could have used
backquoted forms directly in the syntax rules to generate lisp while
parsing). Here again is a place where I think you could do much better than
ANTLR. I have a small example that generates lisp from XPath expressions,
improves the token reading a bit too -- if anyone wants to see examples,
just let me know. It's not on sourceforge yet...
Zebu is decades old and badly in need of a face lift -- it seems to be
mostly an experiment in reversible grammars (or some such thing -- I forgot
what they called it). We can do better than this today.
--
Best regards,
- Peter
Peter Denno <······@starpower.net> writes:
> What's wrong with using the lisp reader for the lexer?
For tokens which resemble Lisp it's optimal to use the Lisp
reader. However, if you have strange numbers (e.g. Verilog numbers on
the form 16'hacdc), odd comments, tokens spanning lines etc. I find it
easier to describe tokens using a simple syntax where the generator
will generate efficient code to recognize the tokens.
It's just like you use a parser-generator to generate code from you
productions rather than coding the parser in Lisp. Same thing for the
lexical analyzer.
You can do some token specifications using :lex-cats in Zebu, but it's
limited.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is
the most annoying thing on usenet and in e-mail?