You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(57) |
Jun
(24) |
Jul
(34) |
Aug
(14) |
Sep
(1) |
Oct
(7) |
Nov
(4) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(11) |
Feb
(1) |
Mar
(2) |
Apr
(10) |
May
(2) |
Jun
(16) |
Jul
(9) |
Aug
(1) |
Sep
(1) |
Oct
(9) |
Nov
(4) |
Dec
(2) |
2007 |
Jan
(10) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matthieu M. <Mat...@gr...> - 2010-07-29 09:44:42
|
Hung Xuan Nguyen <st...@gm...> writes: > Hello greensocs mailing lists. Hi, > - We also have involve with some used of TLM 2.0 , but from what i know, > pinapa onl support with TLM 1.0 . I have tried to > include the tlm.h on the build configuration but it doesn't work that way. > So i am having the question : > > (1) Is pinapa will be support for the TLM 2.0 ( for the next version , maybe > ) ? Pinapa itself it no longer actively developped, and its active developpement period stoped before the release of TLM-2, hence your problem. We're now working on a complete rewrite, called PinaVM ( http://gitorious.org/pinavm/pages/Home ), so unfortunately, I can't afford to spend much time on Pinapa. Still, since Pinapa is open-source, you're free to add support for the features you require. Supporting the raw TLM-2 interface is hard, since a transaction can be a piece of code like // build the payload ... trans->set_command(tlm::TLM_READ_COMMAND); trans->set_address(addr); trans->set_data_ptr(reinterpret_cast<unsigned char*>(&data)); // No block transaction => just one piece of data trans->set_data_length(sizeof(data_t)); // no streaming => streaming_width == data_length trans->set_streaming_width(sizeof(data_t)); // ... and send it. (*this)[port]->b_transport(*trans, time); which is difficult to pattern-match. What would be relatively simple to add would be a convenience API built on top of this (i.e. something providing simple methods like socket.read(...) and socket.write(...)). If you look at what the code does for TAC and BASIC, it should be fairly straightforward to mimick this for another conveinience interface. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ |
From: Hung X. N. <st...@gm...> - 2010-07-29 04:52:13
|
Hello greensocs mailing lists. - We have been writing the back-end for the Pinapa, and we mostly using AST and ELAB extract from Pinapa for our project ( sorry to say it is confidential information, and i can't explain clearly on it ). - We also have involve with some used of TLM 2.0 , but from what i know, pinapa onl support with TLM 1.0 . I have tried to include the tlm.h on the build configuration but it doesn't work that way. So i am having the question : (1) Is pinapa will be support for the TLM 2.0 ( for the next version , maybe ) ? (2) is there any other approach way to use TLM2.0 on currently release of Pinapa ? I am really appreciate for the answers. Thank you in advance. |
From: Bruce <bru...@gm...> - 2010-04-19 16:02:13
|
Dear Moy, > The drawback of PinaVM is that it's younger than Pinapa (hence some > parts are still half-finished), but otherwise, PinaVM should be both > simpler and more powerfull. I see. I will read more information about PinaVM first before I do. Thanks for your help! Bruce -- |
From: Matthieu M. <Mat...@gr...> - 2010-04-19 15:58:00
|
"Bruce" <bru...@gm...> writes: > Hi Moy, > > Thanks for your help. > > I have successfully build PINAPA on Ubuntu 8.04. Therefore, I think > version of some tools on my > AS 3 does not match that you use. That's possible, yes. > I want to use PINAPA to design a SystemC to Verilog synthesis tool as my > school project. I am now > learn some basis of GCC. But your recommended PinaVM is based on LLVM. I > am wondering what is the > difference between them? And whose source code is easier to learn? The drawback of PinaVM is that it's younger than Pinapa (hence some parts are still half-finished), but otherwise, PinaVM should be both simpler and more powerfull. Read section 4 of the report about PinaVM for details: http://www-verimag.imag.fr/Technical-Reports,264.html?lang=en&number=TR-2010-8 -- Matthieu Moy http://www-verimag.imag.fr/~moy/ |
From: Bruce <bru...@gm...> - 2010-04-19 15:36:33
|
Hi Moy, Thanks for your help. I have successfully build PINAPA on Ubuntu 8.04. Therefore, I think version of some tools on my AS 3 does not match that you use. I want to use PINAPA to design a SystemC to Verilog synthesis tool as my school project. I am now learn some basis of GCC. But your recommended PinaVM is based on LLVM. I am wondering what is the difference between them? And whose source code is easier to learn? Thanks again~ Bruce -- > -----Original Message----- > From: Matthieu Moy [mailto:Mat...@gr...] > Sent: Monday, April 19, 2010 9:15 PM > To: Bruce > Cc: gre...@li...; Kevin Marquet > Subject: Re: [Greensocs-pinapa] fail to build PINAPA using build.sh > > "Bruce" <bru...@gm...> writes: > > > Hi, > > Hi, > > First of all, if you're considering using Pinapa, you should also have > a look at PinaVM, which is more or less the successor of Pinapa. It's > still very much a prototype, but starts working well. In short, it's > based on LLVM instead of GCC, and this makes it both more powerfull > and easier to use/install. > > Waiting for a better documentation, you can start here: > > http://gitorious.org/pinavm/pages/Home > > > According to instructions on the website, I download package of > > 'pinapa-expl-sc-2.1.v1-snapshot.tar.gz' > > and run './build.sh' > [...] > > + compile_gcc > > + cd /public/soc/systemc/pinapa/pinapa-expl/build.tmp/pinapa > > + '[' xno = xno -o '(' '!' -f > > /public/soc/systemc/pinapa/pinapa-expl/ext.tmp/gcc- > 3.4.1/objs/libfullgcc.so > > ')' ']' > > + /usr/local/bin/make gcc-all > > Makefile:1290: .deps/libpinapa_la-pinapa-analyze-body-utils.Plo: No > such > > file or directory > > I can't reproduce here. These are (automake+libtool)-generated files, > I guess you either have a strange version of automake, or messed-up > something after the download (the autotools are cool when they work, > but a nightmare to debug when they fail, unfortunately). > > If you re-run build.sh several times, you probably want to use --lazy. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ |
From: Bruce <bru...@gm...> - 2010-04-17 20:15:29
|
Hi, According to instructions on the website, I download package of 'pinapa-expl-sc-2.1.v1-snapshot.tar.gz' and run './build.sh' However, some errors occur and building fail. I then run './build.sh >& build.log' and attached the log file in the mail. Can anyone help me see what is wrong? My OS is RedHat AS3, My GCC version is 3.4.6, and my make version is 3.81 Nearby messages for where build fail is listed here: + PINAPA_GET=wget + echo 'Using wget to get the patches' Using wget to get the patches ++ dirname /public/soc/systemc/pinapa/pinapa-expl/pinapa/build.sh + cd /public/soc/systemc/pinapa/pinapa-expl/pinapa ++ pwd + srcdir=/public/soc/systemc/pinapa/pinapa-expl/pinapa + '[' x/public/soc/systemc/pinapa/pinapa-expl/build.tmp/pinapa = x ']' + '[' x/public/soc/systemc/pinapa/pinapa-expl/ext.tmp = x ']' + '[' xpostconfig '!=' xnothing ']' + '[' '!' -d /public/soc/systemc/pinapa/pinapa-expl/build.tmp/pinapa ']' + '[' '!' -d /public/soc/systemc/pinapa/pinapa-expl/ext.tmp ']' + gccdir=/public/soc/systemc/pinapa/pinapa-expl/ext.tmp/gcc-3.4.1 + basic_check + g++ --version + grep '(GCC) 3.4' GCC version is 3.4 + compile_gcc + cd /public/soc/systemc/pinapa/pinapa-expl/build.tmp/pinapa + '[' xno = xno -o '(' '!' -f /public/soc/systemc/pinapa/pinapa-expl/ext.tmp/gcc-3.4.1/objs/libfullgcc.so ')' ']' + /usr/local/bin/make gcc-all Makefile:1290: .deps/libpinapa_la-pinapa-analyze-body-utils.Plo: No such file or directory Makefile:1291: .deps/libpinapa_la-pinapa-analyze-body.Plo: No such file or directory Makefile:1292: .deps/libpinapa_la-pinapa-backend.Plo: No such file or directory Makefile:1293: .deps/libpinapa_la-pinapa-basic-slave-process.Plo: No such file or directory Makefile:1294: .deps/libpinapa_la-pinapa-build-gcc-command.Plo: No such file or directory Makefile:1295: .deps/libpinapa_la-pinapa-bypass.Plo: No such file or directory Makefile:1296: .deps/libpinapa_la-pinapa-config.Plo: No such file or directory Makefile:1297: .deps/libpinapa_la-pinapa-decoration.Plo: No such file or directory Makefile:1298: .deps/libpinapa_la-pinapa-extend-slave-process.Plo: No such file or directory Makefile:1299: .deps/libpinapa_la-pinapa-finalize.Plo: No such file or directory Makefile:1300: .deps/libpinapa_la-pinapa-get-initial-values.Plo: No such file or directory Makefile:1301: .deps/libpinapa_la-pinapa-initialize.Plo: No such file or directory Makefile:1302: .deps/libpinapa_la-pinapa-interfaces-and-slaves.Plo: No such file or directory Makefile:1303: .deps/libpinapa_la-pinapa-main.Plo: No such file or directory Makefile:1304: .deps/libpinapa_la-pinapa-module-decoration.Plo: No such file or directory Makefile:1305: .deps/libpinapa_la-pinapa-parser-all.Plo: No such file or directory Makefile:1306: .deps/libpinapa_la-pinapa-parser-flags.Plo: No such file or directory Makefile:1307: .deps/libpinapa_la-pinapa-parser-getopt.Plo: No such file or directory Makefile:1308: .deps/libpinapa_la-pinapa-port-to-port-hook.Plo: No such file or directory Makefile:1309: .deps/libpinapa_la-pinapa-read-write.Plo: No such file or directory Makefile:1310: .deps/libpinapa_la-pinapa-sc-interface-list-hook.Plo: No such file or directory Makefile:1311: .deps/libpinapa_la-pinapa-sc-object-deco.Plo: No such file or directory Makefile:1312: .deps/libpinapa_la-pinapa-sc-process.Plo: No such file or directory Makefile:1313: .deps/libpinapa_la-pinapa-sensitive-hook.Plo: No such file or directory Makefile:1314: .deps/libpinapa_la-pinapa-simcontext.Plo: No such file or directory Makefile:1315: .deps/libpinapa_la-pinapa-tac-slave-process.Plo: No such file or directory Makefile:1316: .deps/libpinapa_la-pinapa-tree-decoration.Plo: No such file or directory Makefile:1317: .deps/libpinapa_la-pinapa-tree-utils.Plo: No such file or directory Makefile:1318: .deps/libpinapa_la-tac_metadata.Plo: No such file or directory Makefile:1319: .deps/libpinapa_la-tlm_command_line.Plo: No such file or directory Makefile:1320: .deps/libpinapa_la-tlm_message.Plo: No such file or directory Makefile:1321: .deps/libpinapa_la-tlm_message_default.Plo: No such file or directory Makefile:1322: .deps/libpinapa_la-tlm_module.Plo: No such file or directory Makefile:1323: .deps/libpinapa_la-tlm_pvt_base.Plo: No such file or directory Makefile:1324: .deps/libpinapa_la-tlm_time_unit.Plo: No such file or directory Makefile:1325: .deps/libpinapa_la-tlm_transaction_counter.Plo: No such file or directory Makefile:1326: .deps/libpinapa_la-tlm_transrecord_database.Plo: No such file or directory Makefile:1329: *** missing separator. Stop. + echo 'GCC compile error' GCC compile error + exit 1 + echo 'Pinapa postconfig failed' Pinapa postconfig failed + exit 1 --- Bruce -- |
From: Rob Q. <rob...@gm...> - 2010-04-06 21:52:29
|
Hey Matthieu, Thanks for your email and thanks for the link to pinavm. It sounds like a really great tool. I downloaded and ran the install-pinapa.sh script and it seems to have built ok although I did have to include the pinavm utils folder (-I$PINAVM/utils) to compile the frontend according to the INSTALL doc otherwise it gave an error "Process.cpp:5:19: error: utils.h: No such file or directory" I'm trying to compile the systemc examples now but if I type make in, for example, the systemc-examples/event folder I receive an error about the typeHelper: g++ main.cpp -o main.exe ../../toplevel/libpinapa.so /home/robquigley/Downloads//lib/systemc-2.2.0-gcc/lib-linux/libsystemc.a -I/home/robquigley/Downloads//lib/systemc-2.2.0-gcc/ -I/home/robquigley/Downloads//lib/systemc-2.2.0-gcc/include -I/home/robquigley/Downloads//lib/systemc-2.2.0-gcc/include/sysc main.cpp: In constructor ‘mytop::mytop(sc_core::sc_module_name)’: main.cpp:13: error: ‘typeHelper’ was not declared in this scope make: *** [main.exe] Error 1 Maybe there is something i'm missing from the command line? Is this the correct way to build the examples in the systemc-examples folder? Maybe there is more to linking the examples with the backend. The tool sounds very useful, any help would be great! Cheers Matthieu, Rob. On Fri, Apr 2, 2010 at 12:31 PM, Matthieu Moy <Mat...@gr...>wrote: > Rob Quigley <rob...@gm...> writes: > > > Hey everybody! > > > > I'm just new to PINAPA and I found it while looking for different SystemC > > front-ends. > > You can have a look at this report: > > > http://www-verimag.imag.fr/Technical-Reports,264.html?lang=/&number=TR-2010-4 > > for a survey on existing SystemC front-ends. > > Note that we're currently working on a new version of Pinapa. It's > still a prototype, but should overcome most of the issues with Pinapa. > It's called PinaVM, and is available here: > > http://gitorious.org/pinavm > > It doesn't have much documentation as of now, but there should be a > research report available in the next few weeks. > > > I compiled and ran the two examples ok but the first example is > > returning "unknown > > type" for pinapa::treeFacade::get_type_name(node) or > > pinapa::treeFacade::get_name(node) in the virtual int visitCallExpr(const > > tree node). Should this be what is returned? It seems to iterate over all > > the objects ok but not when it gets to the processes. Maybe it is > supposed > > to return "unknown type"? I'm new so I said I would just ask to see. > > Unfortunately, this part of the code is not one I've written, and I'm > not familiar with it. It seems your example is using the << operator > on something that Pinapa doesn't know about. It shouldn't be serious: > Pinapa only really cares about read/write on ports. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ <http://www-verimag.imag.fr/%7Emoy/> > |
From: Rob Q. <rob...@gm...> - 2010-04-01 18:33:43
|
Hey everybody! I'm just new to PINAPA and I found it while looking for different SystemC front-ends. I compiled and ran the two examples ok but the first example is returning "unknown type" for pinapa::treeFacade::get_type_name(node) or pinapa::treeFacade::get_name(node) in the virtual int visitCallExpr(const tree node). Should this be what is returned? It seems to iterate over all the objects ok but not when it gets to the processes. Maybe it is supposed to return "unknown type"? I'm new so I said I would just ask to see. Thanks everybody! Rob. cd pinapa && make make[1]: Entering directory `/home/robquigley/tools/pinapa/my-pinapa-example/build.tmp/pinapa' make all-am make[2]: Entering directory `/home/robquigley/tools/pinapa/my-pinapa-example/build.tmp/pinapa' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/robquigley/tools/pinapa/my-pinapa-example/build.tmp/pinapa' make[1]: Leaving directory `/home/robquigley/tools/pinapa/my-pinapa-example/build.tmp/pinapa' /bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o example main.o -L/home/robquigley/tools/pinapa/pinapa-expl-sc-2.1.v1/ext.tmp/gcc-3.4.1/objs -L/home/robquigley/tools/pinapa/pinapa-expl-sc-2.1.v1/build.tmp/pinapa -lpinapa g++ -g -O2 -o .libs/example main.o -L/home/robquigley/tools/pinapa/pinapa-expl-sc-2.1.v1/ext.tmp/gcc-3.4.1/objs -L/home/robquigley/tools/pinapa/pinapa-expl-sc-2.1.v1/build.tmp/pinapa /home/robquigley/tools/pinapa/pinapa-expl-sc-2.1.v1/build.tmp/pinapa/.libs/libpinapa.so -lfullgcc -ldl /usr/local/lib/libstdc++.so -L/home/robquigley/gcc-files/gcc-4.0-source/tool/i686-pc-linux-gnu/libstdc++-v3/src -L/home/robquigley/gcc-files/gcc-4.0-source/tool/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/robquigley/gcc-files/gcc-4.0-source/tool/gcc -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.4 -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.4/../../.. creating example ./example ./preprocessed_file.cpp ./libplatform.so Welcome the the example for my SystemC parser I'm now going to parse your system. SystemC 2.1.v1 --- Mar 23 2010 16:40:28 Copyright (c) 1996-2005 by all Contributors ALL RIGHTS RESERVED SystemC OSCI_PINAPA, based on OSCI 2.1v1 Dlopen'ing library ./libplatform.so... done. Launching the front-end on file ./preprocessed_file.cpp Parsing OK. OK. Here am I again :-) Rob found object TOP of kind sc_module Rob found object TOP.fifo_0 of kind sc_fifo Rob found object TOP.m_emitter_name of kind sc_module Rob found object TOP.m_emitter_name.emitter_process of kind sc_thread_process Rob found object TOP.m_emitter_name.port_0 of kind sc_out . . . . . current node is a le_expr current node is a var_decl Var Decl for z Initial value Decl for z <integer_cst 0x426a01c8 type <integer_type 0x40fbb620 int> constant 0> current node is a integer_cst current node is a integer_cst current node is a scope_stmt current node is a compound_stmt current node is a scope_stmt current node is a expr_stmt current node is a convert_expr current node is a call_expr Call Expr for *unknown type* <addr_expr 0x4268fee8 type <pointer_type 0x4234e930 type <method_type 0x41a762a0 type <reference_type 0x41758930> DI size <integer_cst 0x40fb96d8 constant 64> unit size <integer_cst 0x40fb9b10 constant 8> align 64 symtab 0 alias set -1 method basetype <record_type 0x413927e0 basic_ostream<char,std::char_traits<char> >> arg-types <tree_list 0x41a74a80 value <pointer_type 0x413928c0> chain <tree_list 0x41a74a50 value <pointer_type 0x41a76230> chain <tree_list 0x41159e10 tree_2 value <void_type 0x41157d20 void>>>> pointer_to_this <pointer_type 0x4234e930>> unsigned SI size <integer_cst 0x40fb9b58 constant 32> unit size <integer_cst 0x40fb9bb8 constant 4> align 32 symtab 0 alias set -1> arg 0 <function_decl 0x41a76310 operator<< type <method_type 0x41a762a0> used public static in_system_header external inline defer-output decl_1 decl_5 QI file /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../include/c++/3.4.6/bits/ostream.tcc line 63 context <record_type 0x413927e0 basic_ostream<char,std::char_traits<char> >> arguments <parm_decl 0x42fc5150 this type <pointer_type 0x41a73a80> readonly unsigned used in_system_header SI file /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../include/c++/3.4.6/bits/ostream.tcc line 63 size <integer_cst 0x40fb9b58 32> unit size <integer_cst 0x40fb9bb8 4> align 32 context <function_decl 0x41a76310 operator<<> initial <pointer_type 0x41a73a80> arg-type <pointer_type 0x41a73a80> chain <parm_decl 0x42fc5230 __pf>> result <result_decl 0x42fc52a0 type <reference_type 0x41758930> readonly unsigned SI file /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../include/c++/3.4.6/bits/ostream.tcc line 63 size <integer_cst 0x40fb9b58 32> unit size <integer_cst 0x40fb9bb8 4> align 32 context <function_decl 0x41a76310 operator<<>> initial <block 0x42fa7d00> pending-inline-info 0x42fc53f0 template-info 0x41a74a98 saved-insns 0x42bd3200 chain <function_decl 0x41a76620 operator<< type <method_type 0x41a765b0> public in_system_header external inline defer-output QI file /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../include/c++/3.4.6/bits/ostream.tcc line 74 context <record_type 0x413927e0 basic_ostream<char,std::char_traits<char> >> arguments <parm_decl 0x41a76690 this> template-info 0x41a74b70 saved-insns 0x418b1800 chain <function_decl 0x41a768c0 operator<<>>>> current node is a function_decl current node is a tree_list |
From: Bailey M. <bm...@cs...> - 2009-05-04 20:06:30
|
Thank you for the reply Matthieu, Once the port argument was changed to the call_expr node, I was able to retrieve the related object and its corresponding name. Thanks!!! Thanks, Bailey Matthieu Moy wrote: > bm...@cs... writes: > > >> Thanks for the reply Matthieu, >> >> It's good to know that Pinapa can solve this issue, although I had a >> problem in implementing the example code that you provided. >> > > (I'm very busy, and I haven't worked on Pinapa for some time, so > apologize for the incomplete reply) > > >> I construct the key_assoc_tree_handle with: >> port = first operand of call_expr (which is an addr_expr pointing >> to write() function). >> h = the sc_process_handle for the process() function found in >> the 'test' module of my example code. >> > > probably "port" doesn't contain the right thing (probably I > miss-guided you in my earlier email). After a quick look at the code, > I think it should actually be the CALL_EXPR node itself, or the port > argument (pinapa decorates both, to be sure). Anyway, the decoration > is done in pinapa-read-write.cpp, at the bottom, see the lines: > > (*d)->set_related_object(a->m_port, a->m_handle); > d->attach(function); > (*d2)->set_related_object(a->m_port, a->m_handle); > > At worse, put a breakpoint on this d->attach(function), and see what > "function" contains (in gdb, do p debug_tree(function)), or at the top > of the function, look at the gcc_port variable. > > |
From: Matthieu M. <Mat...@im...> - 2009-05-04 19:43:18
|
bm...@cs... writes: > Thanks for the reply Matthieu, > > It's good to know that Pinapa can solve this issue, although I had a > problem in implementing the example code that you provided. (I'm very busy, and I haven't worked on Pinapa for some time, so apologize for the incomplete reply) > > I construct the key_assoc_tree_handle with: > port = first operand of call_expr (which is an addr_expr pointing > to write() function). > h = the sc_process_handle for the process() function found in > the 'test' module of my example code. probably "port" doesn't contain the right thing (probably I miss-guided you in my earlier email). After a quick look at the code, I think it should actually be the CALL_EXPR node itself, or the port argument (pinapa decorates both, to be sure). Anyway, the decoration is done in pinapa-read-write.cpp, at the bottom, see the lines: (*d)->set_related_object(a->m_port, a->m_handle); d->attach(function); (*d2)->set_related_object(a->m_port, a->m_handle); At worse, put a breakpoint on this d->attach(function), and see what "function" contains (in gdb, do p debug_tree(function)), or at the top of the function, look at the gcc_port variable. -- Matthieu |
From: <bm...@cs...> - 2009-05-01 02:29:56
|
Thanks for the reply Matthieu, It's good to know that Pinapa can solve this issue, although I had a problem in implementing the example code that you provided. I construct the key_assoc_tree_handle with: port = first operand of call_expr (which is an addr_expr pointing to write() function). h = the sc_process_handle for the process() function found in the 'test' module of my example code. I don't think this is correct because when I attempt to use the get_related_object() function to retrieve an sc_object* in the next line, I get a null pointer. Without getting into too much detail, I'm using Pinapa to generate bytecode for systemC models. Thanks, Bailey > bm...@cs... writes: > >> Hi there, > > Hi, and thanks for your interest in Pinapa (if it's not confidential, > I'd appreciate if you give an idea of your usage of Pinapa). > >> I am building a backend for Pinapa, and I need help in retrieving port >> names during a function call when examining an AST. For example, I have >> the following module. >> >> class test : public sc_module { >> public: >> sc_in_clk clock; >> sc_out<sc_uint<32> > output; >> >> SC_HAS_PROCESS(test); >> test(sc_module_name n) : sc_module(n) { >> SC_THREAD(process); >> sensitive << clock.pos(); >> } >> >> void process() { >> output.write(10); //Need to find a reference to output in AST here >> } >> }; >> >> I can't find any references to 'output' in the AST of the CALL_EXPR >> node. > > Yes, this is something GCC "destroys" (breaks down into pointer > arithmetics). > >> Is this something that Pinapa adds as a decoration to the tree? > > It should, yes. > >> I don't quite understand the usage of the decoration tree yet, could >> someone explain how one might go about retrieving such information? > > That's the method get_related_object() for the decoration. > > But for a given AST, you can have several instance of process > (typically, if you instanciated the module several times). So, you > have to give both the AST and the concrete process handler to get a > port (the key for the hash table is "tree_handle", which is just > this). This should give something like: > > where "port" is the AST for the first operand of the CALL_EXPR, and h > is the process handler: > > pinapa::key_assoc_tree_handle k(port,h); > sc_object * o = > pinapa::st_tree_instance_deco::get(&k)->get_related_object(); > > and then, to check that it worked: > > sc_port_base * p = PINAPA_SCAST<sc_port_base *>(o); > name = p->name(); > > (but "name" here will be the name of the SystemC object, not the name > of the variable). > > -- > Matthieu > |
From: Matthieu M. <Mat...@im...> - 2009-04-30 20:56:47
|
bm...@cs... writes: > Hi there, Hi, and thanks for your interest in Pinapa (if it's not confidential, I'd appreciate if you give an idea of your usage of Pinapa). > I am building a backend for Pinapa, and I need help in retrieving port > names during a function call when examining an AST. For example, I have > the following module. > > class test : public sc_module { > public: > sc_in_clk clock; > sc_out<sc_uint<32> > output; > > SC_HAS_PROCESS(test); > test(sc_module_name n) : sc_module(n) { > SC_THREAD(process); > sensitive << clock.pos(); > } > > void process() { > output.write(10); //Need to find a reference to output in AST here > } > }; > > I can't find any references to 'output' in the AST of the CALL_EXPR > node. Yes, this is something GCC "destroys" (breaks down into pointer arithmetics). > Is this something that Pinapa adds as a decoration to the tree? It should, yes. > I don't quite understand the usage of the decoration tree yet, could > someone explain how one might go about retrieving such information? That's the method get_related_object() for the decoration. But for a given AST, you can have several instance of process (typically, if you instanciated the module several times). So, you have to give both the AST and the concrete process handler to get a port (the key for the hash table is "tree_handle", which is just this). This should give something like: where "port" is the AST for the first operand of the CALL_EXPR, and h is the process handler: pinapa::key_assoc_tree_handle k(port,h); sc_object * o = pinapa::st_tree_instance_deco::get(&k)->get_related_object(); and then, to check that it worked: sc_port_base * p = PINAPA_SCAST<sc_port_base *>(o); name = p->name(); (but "name" here will be the name of the SystemC object, not the name of the variable). -- Matthieu |
From: <bm...@cs...> - 2009-04-29 19:29:22
|
Hi there, I am building a backend for Pinapa, and I need help in retrieving port names during a function call when examining an AST. For example, I have the following module. class test : public sc_module { public: sc_in_clk clock; sc_out<sc_uint<32> > output; SC_HAS_PROCESS(test); test(sc_module_name n) : sc_module(n) { SC_THREAD(process); sensitive << clock.pos(); } void process() { output.write(10); //Need to find a reference to output in AST here } }; I can't find any references to 'output' in the AST of the CALL_EXPR node. Is this something that Pinapa adds as a decoration to the tree? I don't quite understand the usage of the decoration tree yet, could someone explain how one might go about retrieving such information? Thanks for any help, it is much appreciated! :) Thanks, Bailey |
From: Matthieu M. <Mat...@im...> - 2007-07-17 20:56:16
|
Hi, GUEDON <ste...@do...> writes: > I tried the package sc2spirit. A lot of problems due to the "configure" > step. Does somebody had success into it? I ported the "build.sh" thing from the examples to SC2Spirit. I've just uploaded it, it works for me (I wouldn't say it's well tested). For the record, SC2Spirit was developped by STMicroelectronics, based on my work on Pinapa (I developped Pinapa as part of my Ph.D thesis, as an STMicroelectronics employee). However, I'm not the author of SC2Spirit (the author is Frédéric Saunier), which explains why I have difficulties to support it ;-). Still, STMicroelectronics allowed me to release it as free software. A remark about the name: the initial name was SPINAPA (Spirit + Pinapa), but it later changed to SC2Spirit. That explains why the tarball and a few other things are called spinapa, while the official name is now SC2Spirit. Please, try again with http://greensocs.sourceforge.net/pinapa/download/files/spinapa-snapshot.tar.gz and using the "build.sh" script. -- Matthieu |
From: GUEDON <ste...@do...> - 2007-07-12 16:40:15
|
I tried the package sc2spirit. A lot of problems due to the "configure" step. Does somebody had success into it? Thanks. |
From: GUEDON <ste...@do...> - 2007-07-12 08:37:00
|
I downloaded "sc2spirit". The "./autogen.sh" fails claiming: "autoheader: error: AC_CONFIG_HEADERS not found in configure.ac" Probably the interpretor didn't appreciated that "platform/include/top.h.in" is done in AC_CONFIG_LINKS? I do not know. Thanks for help Stéphane Guédon Configuration: PC Linux Open Suse gcc and g++ 3.4.1 |
From: GUEDON <ste...@do...> - 2007-07-11 13:49:29
|
To pinapa'fans, I 've compiled pinapa-expl. I would like to post the pbs i have encountered. (pb1) running ./build.sh at "pinapa-expl" level, after "pinapa-expl/pinapa" unpacked, the basic_check() claims a bad version of GCC. Normal, the variable CXX is not set. I have been informed to set it to G++. (pb2) the "--get-method" option is not given to pinapa-expl/pinapa/build.sh. I added it in pinapa_preconfig() and pinapa_postconfig(). My configuration: . PC Linux Open Suse . gcc and g++ 3.4.1 . bashrc |
From: Matthieu M. <Mat...@im...> - 2007-03-26 09:50:30
|
Hi all, I'll just start with a bit of history: I completed my Ph.D (during which I wrote Pinapa) in December 2005, and stopped the development of Pinapa while I was doing my post-doc. STMicroelectronics continued the development internally, but did not make any release (simply by lack of time). I'm now back to Verimag, and back to Pinapa's development. I have very limited time to spend on this, but I'm working on a release of the improvements developped in 2006. They include: * Support for SystemC 2.1 * Support for Solaris Additionnaly, I'm migrating to bzr instead of the now deprecated Bazaar. Not that I'm 100% satisfied with bzr, but it seems to be the most reasonable at the moment. This means that the website and download area might be semi-broken for some time. The old snapshots are kept here: http://greensocs.sourceforge.net/pinapa/download/files/old/ -- Matthieu |
From: Matthieu M. <Mat...@im...> - 2007-03-23 16:36:19
|
"Dario Vieira" <dar...@gm...> writes: > Hi, > > I'm trying to compile the Pinapa. However, > I run into problem as you can see bellow: You seem to be using GCC 3.4.6, while Pinapa contains a patch against 3.4.1. See if it works with the correct version of GCC first. Otherwise, give more details on your platform here (OS, version, ...). Regards, -- Matthieu |
From: Dario V. <dar...@gm...> - 2007-03-23 15:43:41
|
Hi, I'm trying to compile the Pinapa. However, I run into problem as you can see bellow: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D gcc -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -fno-common -DHAVE_CONFIG_H -o cc1 \ c-parse.o c-lang.o c-pretty-print.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o libcpp.a main.o libbackend.a ../libiberty/libiberty.a c-common.o : Dans la fonction "handle_vector_size_attribute":/localhome/dario/pinapa/ext.tmp/gcc- 3.4.6 /gcc/c-common.c:5299: r=E9f=E9rence ind=E9finie vers =AB reconstruct_comple= x_type =BB libbackend.a(toplev.o) : Dans la fonction "compile_file":/localhome/dario/pinapa/ext.tmp/gcc-3.4.6/gcc/toplev.c:1864: r=E9f=E9rence ind=E9finie vers =AB process_pending_assemble_output_defs =BB collect2: ld a retourn=E9 1 code d'=E9tat d'ex=E9cution make[4]: *** [cc1] Erreur 1 make[4]: quittant le r=E9pertoire =AB /localhome/dario/pinapa/ext.tmp/gcc-3.4.6/objs/gcc =BB make[3]: *** [stage1_build] Erreur 2 make[3]: quittant le r=E9pertoire =AB /localhome/dario/pinapa/ext.tmp/gcc-3.4.6/objs/gcc =BB make[2]: *** [bootstrap] Erreur 2 make[2]: quittant le r=E9pertoire =AB /localhome/dario/pinapa/ext.tmp/gcc-3.4.6/objs =BB make[1]: *** [gcc-bootstrap] Erreur 2 make[1]: quittant le r=E9pertoire =AB /localhome/dario/pinapa/build.tmp =BB make: *** [gcc-bootstrap] Erreur 2 + echo 'GCC compile error' GCC compile error + exit 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Do you have any idea how to fix this bug? Best Regard, Dario |
From: Matthieu M. <Mat...@im...> - 2007-01-18 07:56:07
|
"Zonghua Gu" <zg...@cs...> writes: > I am getting a lot of build errors. Is it possible to provide a Linux > binary executable to avoid the build process? This is made illegal by the GCC licence (GPL) which is incompatible with the one of SystemC :-(. Furthermore, the whole SystemC + GCC + Pinapa is quite complex, and I suspect you'd get even more problems with the ABI than you get compiling it. -- Matthieu |
From: Matthieu M. <Mat...@im...> - 2007-01-18 07:53:37
|
"GUAN NAN" <gua...@ho...> writes: > Dear Moy, > > The bootstrap is failed. It fails when called from Pinapa's build script. But are you able to bootstrap the same version of GCC by hand (Pinapa patches the code slightly)? Instructions are available here: http://gcc.gnu.org/install/ If this fails, then you have a GCC problem, which I won't be able to solve (the GCC team might on the other hand). Otherwise, we can keep hope and investigate further ... -- Matthieu |
From: GUAN N. <gua...@ho...> - 2007-01-18 05:07:15
|
Dear Moy, The bootstrap is failed. " ...... Bootstrap comparison failure! ./gcc.o differs make[3]: *** [gnucompare] Error 1 make[3]: Leaving directory `/homes/zgu/guannan/lctes07/pinapadownload/pinapa-expl/ext.tmp/gcc-3.4.1/objs/gcc' make[2]: *** [bootstrap] Error 2 make[2]: Leaving directory `/homes/zgu/guannan/lctes07/pinapadownload/pinapa-expl/ext.tmp/gcc-3.4.1/objs' make[1]: *** [gcc-bootstrap] Error 2 make[1]: Leaving directory `/homes/zgu/guannan/lctes07/pinapadownload/pinapa-expl/build.tmp/pinapa' make: *** [gcc-bootstrap] Error 2 + echo 'GCC compile error' GCC compile error + exit 1 + echo 'Pinapa postconfig failed' Pinapa postconfig failed + exit 1 ......" >From: Matthieu Moy <Mat...@im...> >To: "GUAN NAN" <gua...@ho...> >CC: gre...@li... >Subject: Re: [Greensocs-pinapa] building errors >Date: Wed, 17 Jan 2007 18:20:42 +0100 > >"GUAN NAN" <gua...@ho...> writes: > > > The OS is Fedora Linux Core 3.0 (x86_64 Edition), the GCC is 3.4.3. > > What's your usual running enviroment? > >I'm running Debian stable, and I used to use Linux RedHat too. > >Does GCC 3.4.1 bootstrap on your system ? > >-- >Matthieu _________________________________________________________________ 与世界各地的朋友进行交流,免费下载 Live Messenger; http://get.live.com/messenger/overview |
From: Zonghua G. <zg...@cs...> - 2007-01-18 04:02:00
|
I am getting a lot of build errors. Is it possible to provide a Linux binary executable to avoid the build process? -- Best, Zonghua |
From: Matthieu M. <Mat...@im...> - 2007-01-17 17:48:06
|
"Zonghua Gu" <zg...@cs...> writes: > When I type: > > bzr branch http://greensocs.sourceforge.net/pinapa/Mat...@im...--pinapa/ > > bzr: ERROR: Not a branch: > http://greensocs.sourceforge.net/pinapa/Mat...@im...--pinapa/ > > Am I doing sth wrong here? You're using bzr, which is the "new" version of Bazaar. At the time I've set up Pinapa's archive, bzr didn't exist, and I was using Bazaar 1.4. I'll update all this when I have time, but for now, the best is to use the tarball (tar.gz). -- Matthieu |