boost::format works by operator overloading of the '%' operator (modulus normally). You can define your own overloads that would stub it out, and then #define format() to stub it out. (unless Xilinx's compiler is stumbling on the operator overloads themselves!)
Alternatively, it strikes me as *possibly* not that long a task to create a set of regex's for search and replace to convert to sprintf. The way I would go about that is to come up with a regex that matches a format() call with one replacement (one '%' after the format), and then one for 2 replacements, 3 replacements, etc. This should drastically cut down on the work to convert to sprintf. Note that there may well be a way to do this all with one regex but my regex-fu is not that strong. -Jon On Wed, Apr 1, 2015 at 12:30 PM, Greg London <[email protected]> wrote: > > I have some c++ code that I've been developing for hardware simulation > over the years. > > Very recently I got some cycles to try and port this code as an > executable to the Zedboard, which uses the Xilinx ZYNQ chip, which > has an ARM processor and FPGA fabric. This would give us probably > a couple orders of magnitude in faster executions. And would save > a lot of money in not needing simulation licenses. > > The problem is the Xilinx tools do not seem to like Boost::Format. > > My c++ code looks like this: > > #include <boost/format.hpp> > using boost::format; > using boost::io::group; > string mystr = (format("%s Timercount=%d") % msg % count ) .str(); > > > Unfortunately, I've used boost::format everywhere. > If it was rare, I'd just manually go through it and > convert it to sprintf() or something. > But its literally used thousands of different places > in my code. > > Anyway, I thought maybe there might be a way to roll my own > version of format() so that it just calls sprintf(). > Except I never quite understood the percent separators > in format. > > I basically need something like this: > > string boost::format(%){ > return sprintf(%); > } > > Worst comes to worse, it's an empty function. > I just want to get something to compile on the FPGA. > > It would be nice if the IO could be sent to the > terminal port, which means the stub would have to actually > return something meaningful. But really, the priority > is just getting the code to do memory accesses and the > IO is helpful but not absolutely required. > > Could someone point me to a solution for this? > > Thanks, > Greg > > > > > _______________________________________________ > Hardwarehacking mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/hardwarehacking >
_______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
