On 29 Nov 2013, at 8:39 am, Brian Drummond <[email protected]> wrote:
> Now if the mcode version compiles fsm.vhd just fine, this is pointing to
> the gcc middle and back end...
>
> Searching for the messages shows
> gcc/ggc-page.c: perror ("virtual memory exhausted");
> libiberty/xmalloc.c: "\n%s%sout of memory allocating
> %lu bytes after a total of %lu bytes\n",
> And reading around, the gcc middle and back ends are notoriously memory
> hungry, as they run many (typically hundreds of) optimisation passes.
>
> I tried unsuccessfully to pass -O0 flags on the command line, to see if
> it used less memory with optimisation off.
Nick was kind enough to email me saying his tool does accept (pass) -O0
shortening the now 3:41:56.93 cpu time to around 90 secs purportedly. He just
made the changejust for this. The issues Adrien has are serving well for his
tool development too.
It may be worth getting the optimization disable working on ghdl. It should
reduce memory usage and execution time during analysis.
I have some directions on how generate an mcode version for OS X that are
easily adaptable for Linux (using an i32 Ada/gcc), for anyone wanting more
immediate gratification. I think this fix would be cause for doing an actual
ghdl release after some more testing, I'm impressed by the Leon3 SoC success,
but widespread release likely implies a bit of formalism in testing, regression
testing, validation, ... I have no idea what sort of testing regimen Tristan
regularly used, it doesn't show up on gna, nor is there a VHDL validation suite.
We seem to have gotten some use out of ghdl-discuss this week (even if I got up
to early this morning and feel like a damaged paretal lobe this is like the
first day of summer here after a week of cold and rain more suited for a
Scottish winter.)
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
