Think of this as two birds with one stone, answering Adrien's question and providing directions on how to build a ghdl mcode version on Linux. Note this was done on an i386 install under lubuntu 12.04 with the gcc and gnat retrieved using synaptics. It might require a little careful reading of gcc documentation to build successfully on a 64 bit Linux distribution. There's a linkage between target architecture and just in time code generation while only i386 is currently supported in the ghdl code base. Essentially you want to build for an i386 target (32 bit instructions).
On 30 Nov 2013, at 7:47 am, Adrien Prost-Boucle <[email protected]> wrote: >> Could you use an mcode version of ghdl if some one made a Linux version? > > Sorry I don't know what could be an mcode version of anything... as far > as google told me it's related to Mac OS X ? > (if that question was for me) > But with a few explanations I can launch many things. An mcode version is the same style of ghdl as currently fielded in Windows and OS X. It's the jit version of ghdl which doesn't include the ability to include foreign functions ( .o files) and doesn't operate as a gcc front end. I built one before answering, took about 5 minutes to build, including fumbling, this was from memory (and I wrote the directions out elaborated a bit in the OS X version's package installer to comply with the spirit of the GPL). Directions: checkout revision r150 and move it to somewhere with a short path from root (/opt is good and will be used as an example). I did this on a Virtual Box VM lubuntu 12.04 i386 image (it's what I had). The idea here was to use an i386 gnat and i386 gcc. It is likely possible to modify the build Makefile(s) to specify an i386 target on an x86_64 machine. I haven't tried and for that you're on your own). Anyway, I have gcc-4.7 and gnat-4.6 installed through synaptics, and this is an i386 machine. The revision 150 directory name is given as revision_150 (I make local copies of revisions, and guess what I called it?) cd /opt/revision_150/translate/ghdldrv If you look in the Makefile there you'll find the default target is linux and i686, which is fine. make (If you're in a location with a path that generates a line longer than 80 characters in default_paths.ads it will not succeed). This will generate ghdl_mcode make install.mcode (This 'installs' the ieee libraries in ../../libraries/ieee) hard link ghdl_mcode to ghdl in the current directory (e.g. /opt/revision_150/translate/ghdldrv) If you have ghdl already installed, find a location in your path ahead of where it found. This could conceivably include modifying your search path. go to that director (e.g. ~/bin) ln -s /opt/revision_150/translate/ghdl ./ghdl rehash if necessary cd to where you have the original tb.vhd (from the day before yesterday) Check to see you have the right ghdl and it's executable. %% which ghdl /home/david_koontz/bin/ghdl %% ghdl --version GHDL 0.30dev (20100112) [Sokcho edition] Compiled with GNAT Version: 4.6 mcode code generator Written by Tristan Gingold. Copyright (C) 2003 - 2010 Tristan Gingold. GHDL is free software, covered by the GNU General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Now try the original tb.vhd: %% ghdl -a tb.vhd %% (And it analyzes without problem in a second or two). If pressed I'll generate a script (dig out a script) to clean out the revision_150 directory leaving just essentials. Essentially it's everything but ghdl_mcode and the ieee libraries. What's left is the ghdl mcode version, and ieee libraries and relative paths between them (don't move anything). The necessary files are around 2 MB if IRC. A peculiarity of the ghdl mcode version is that it doesn't generate object files, directly compiles into memory, doesn't link to foreign object files and doesn't use a separate elaborate command ( ghdl -e). It doesn't hurt to invoke -e. In the ghdl html help file where you encounter reference to the windows version, it should be read as 'windows or other ghdl mcode version'. I've used the ghdl mcode version on OS X to analyze fsm.vhd and using Nick's fsm_test.vhd, running for 10 clocks, out of reset for 50 ns. Took about 2 minutes to elaborate (just in time) and run. This avoids the issue using the gcc front end version of ghdl encounters running out of memory while performing optimization. For Brian's checking whether his patched version of ghdl can still successfully generate an mcode version he would apply the patch(es) before the make operation. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
