1/1 
|
Re: [Fwd: GSC problems]
by SamuelGoto on Oct 24, 2007 |
SamuelGoto
Posts: 3 Joined: Jul 12, 2007 Last seen: Dec 11, 2018 |
||
|
Hi Philipp !!
On 10/18/07, Philipp Klaus Krause pkk at spth.de> wrote:
It seems you're no longer using the address samuel.goto at ic.unicamp.br,
so here's what I wrote to that address and the opencores list some time
ago. Thanks for creating GSC. I'll try to compile it on a 32 bit system
at university next week.
yes, the documentation is quite outdated and this email is no longer
available. use this one instead.
i wasn't subscribed to the cores at opencores mailing list, but now i am =) so
you can reach me here too =)
-------- Original-Nachricht --------
Betreff: GSC problems
Datum: Tue, 25 Sep 2007 11:52:33 +0200
Von: Philipp Klaus Krause pkk at spth.de>
An: Discussion list about free open source IP cores cores at opencores.org>
CC: samuel.goto at ic.unicamp.br
I noticed the GSC SystemC to Verilog translator and want to try it. The
documentation claims it's far superiour to previously existing free
SystemC to Verilog translators.
well, i didn't mean to claim that it is far superiour to previous attemps, but it is definitely far more scalable than others. By scalability I mean that I am using a well stabilished c++ parser (keystone.sf.net) while others are using a hand written c++ lex/yacc parser. This means that gsc has the ability to support all systemc constructs, while other translators are binded to their poor c++ subset parser. by not being far superior than previous attempts I mean that it is a work in progress, and systemc constructs are being added while users send me feedback ( like you ! thanks for your help ! hehe ! ). however, AFAIK, I could say that gsc is superior than opencore's s2v and tabajara ( the only open soucre translators I am aware of ) and quite comparable to synopsys dc_shell ( the only comercial translator I have acess to ). However I have some troubles making it work. These are mostly related to
GSC's use of Keystone.
ok. I, as you may be, am a programmer ... and programmers aren't really good at making user interfaces ( like command lines options, etc ). Therefore, gsc is definitely not as user friendly as one may expect. However, in time, with users feedback, more and more usability features will be added. Keystone assumes sizeof(unsigned int) == sizeof(void *), which isn't
true on 64 bit systems. It assumes yacc's output files are named y_tab.h
and y_tab.c, which was true a long time ago, but these days they're named y.tab.h and y.tab.c. I had to install 32 bit development libraries on my system and compile using gcc-3.4 -m32, g++-3.4 -m32 using linux32 (a tool to make programs think they're running on a 32 bit system). I've managed to compile Keystone, but it still doesn't work: great ! send me the patch and I'll will patch it against the next release ( and send you the kudos, of course =) ). key -I ~/systemc/objdir/include half_adder.cpp
Token Buffer:
0. /usr/local/include/keystone/stubs/fstream:39: traits 1. /usr/local/include/keystone/stubs/fstream:39: > 2. /usr/local/include/keystone/stubs/fstream:40: { 3. /usr/local/include/keystone/stubs/fstream:41: public 4. /usr/local/include/keystone/stubs/fstream:41: : current: 2 last: 4 Failed assertion: base class scope was not of type ClassScope. file: ContextManager.cpp line: 290 which systemc.h are you using ? gsc uses a special systemc.h which overrides most of the #defines such as SC_MODULE, SC_METHOD, etc ... Thus I have some suggestions to improve usability of GSC:
* Provide Keystone binaries on the download page. This would make using
GSC a lot easier and probably remove the dependencies on btyacc and maybe treecc. OK. I'll do this for my architecture (x86 32 bit) and if you build one for yours send it to me.
* Make GSC give an error message if Keystone is not found (currently it
just hangs on the select() call in line 65 of parse.c). OK. Do it as you think it should be done and send me the patch. * I don't think it is necessary to provide graphviz on the download
page. graphviz is included in many Linux distributions, so users won't
have problems finding it. Make the configure script look for graphviz in default loations, not only in /usr/local. I included graphviz in the download page because I didn't tested gsc against other versions of graphviz. Besides, I need all the development headers of graphviz, not only binaries. Philipp |
|||
|
Re: [Fwd: GSC problems]
by Unknown on Oct 25, 2007 |
Not available! | ||
|
Samuel Goto schrieb:
I included graphviz in the download page because I didn't tested gsc
against other versions of graphviz. Besides, I need all the development headers of graphviz, not only binaries. Just changing graphviz_prefix from "/usr/local" to "/usr" in configure.ac I compiled gsc 0.1.1 on my Debian system with the libgraphviz3 and libgraphviz3-dev packages installed. Philipp |
|||
|
Re: [Fwd: GSC problems]
by SamuelGoto on Oct 25, 2007 |
SamuelGoto
Posts: 3 Joined: Jul 12, 2007 Last seen: Dec 11, 2018 |
||
|
great news. did it worked ?
On 10/25/07, Philipp Klaus Krause pkk at spth.de> wrote:
Samuel Goto schrieb:
> I included graphviz in the download page because I didn't tested gsc
> against other versions of graphviz. Besides, I need all the development > headers of graphviz, not only binaries. Just changing graphviz_prefix from "/usr/local" to "/usr" in configure.ac I compiled gsc 0.1.1 on my Debian system with the libgraphviz3 and libgraphviz3-dev packages installed. Philipp |
|||
1/1