On 29 Nov 2013, at 8:39 am, Brian Drummond <[email protected]> wrote: > > So I think this one is worth reporting on > https://gna.org/bugs/?group=ghdl > with the note that the mcode version bypasses gcc's memory-hungry > optimisation passes. > > (Makes me wonder if it's possible to build the mcode version on Linux?)
I have built the mcode version on Linux (32 bit). Note you can't use foreign objects (subprograms) with it. It might be worthwhile in this case. Adrien's generated coded doesn't appear to benefit from optimization either. It also may be worth making an x86_64 version of the mcode ghdl. (Need to tinker with around a half a dozen or so opcode replacements and uncouple i32/i64 size from things like simulation time). There's a mapping of IR constructs to target machine 'macros' of opcode instructions. There's still a SPARC v8 instruction set creeping around in there too. There appears to be little use for optimization other than really big process statements or process statements filled with variable manipulation. Signal transactions performance is defined by the simulation cycle. Nick's llc compile in --native mode of fsm_test just crossed 2 hours 30 minutes of CPU time and is up to 2.75 GB of memory. We seem to have a time/memory trade off here. The bitcode version (akin to ghdl mcode) took around 26 minutes to 'compile', versus the two minutes to elaborate and run under the ghdl mcode version. (You could also note that an mcode version doesn't chase gcc releases, and I can imagine adding foreign object loading.) :-) > Now the other example appears to elaborate successfully > ghdl -a tb.vhd > but the alleged problem is that it fails with "(others => (others => > '0')) to initialise ... I'm not clear ... is this right? > constant in_vectors : invec_type; > constant out_vectors : outvec_type; > > My problem with that file is that the current initialiser for > out_vectors is an aggregate on a single line, 2588734 characters long! > > My text editor won't display it! I tried pasting it into my email client > and had to kill/restart it! So I have my doubts whether ghdl isn't > perhaps truncating it or (unlikely) failing and exiting silently. > > I would like to see this file recreated with a more sane line length. > > - Brian I posted on the line lengths too. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
