I got ghdl revision 108 to build and run. The mcode version as Brian Davis points out is the just in time version of ghdl that doesn't produce object files (it generates an executable image in memory at elaboration time by direct code generation).
Revision 108 straddles ghdl-0.27 and ghdl-0.28 but it's better than nothing while I continue working up to the current current revision level 143, determining why that won't run without segmentation violation. A little background. This on a late 2008 Macbook aluminum unibody (5,1), 2.4 GHz Core 2 Duo, 4 GB SDRAM, running Mac OS X 10.6.7, using GNAT for Mac OX X GCC 4.3 from http://macada.org (http://www.macada.org/macada/Downloads_files/Gnati386-4.3.dmg, 87.7 decimal MBs). It's an i386 only compiler, which means to use GNAT you should have it earlier than any other gcc versions on your machine to use it. This insures you try to compile C code in the ghdl build with compatible object code. I don't really use Xcode as a development environment, but have the latest and greatest and use darwin10 as the target architecture in Macports (x86_64 only). This should work with any Intel Mac from 10.4 onward. The default installation is to /usr/local/ada-4.3/bin which should appear before any other gcc that generates incompatible object files in your search path ($PATH). Checking out ghdl code from the gna.org subversion repository. cd /Applications (assumes you have administrative privileges) svn -r108 co svn://svn.gna.org/svn/ghdl/trunk ghdl This will checkout revision 108 from the subversion repository. cd ghdl/translate/ghdldrv (further addresses relative from ghdl base directory) Here you can either edit Makefile to make target Mac OS X or pass the target any time you are running make. The target is target=i686-darwin You can use i386 if it make you feel better, the darwin is very important, telling the Makefile how to produce translate/ghdldrv/ortho_code-x86-flags.ads This file isn't under version control in Revision 108, and I believe is in later revisions. You can build it directly or all make to build it automatically (because it isn't there). (make (target=i686-darwin) ortho_code-x86-flags.ads) make (target=i686-darwin) will build translate/ghdldrv/ortho_code-x86-flags.ads the first time. This is important because Stack_Boundary is set to 2**4 for Mac OS X. Things in parenthesis are option based on whether you edit the target in translate/ghdldrv/Makefile or want to build ortho_code-x86-flags.ads first. It should contain: with Ortho_Code.X86.Flags_Macosx; package Ortho_Code.X86.Flags renames Ortho_Code.X86.Flags_Macosx; Where the package Flags_Macosx contains the correct value for Stack_Boundary. (This is in ortho/mcode/ortho_code-x86-flags_macosx.ads) After the make (the second one above) completes (successfully) in translate/ghdldrv ln -s ghdl_mcode ghdl This gives you a ghdl command you can use by name. /Applications/ghdl/translate/ghdldrv should be in $PATH so it can be executed. There's one more make command to generate the ghdl libraries and set things up. It probably requires ghdl be found in your search path. There are things that are relative path sensitive, don't try to copy it elsewhere and there is no installation. If the first make fails complaining about unresolved symbols, it's likely you don't have /usr/local/ada-4.3/bin before any other gcc producing incompatible object files from C. make clean allows you to start over cleanly, and it doesn't take long to build ghdl. The last make command: make (target=i686-darwin) install.mcode You could note that this is all command line oriented and the Finder knows nothing about it, so the installation could be anywhere as long as the ghdl command shows up in your search path. svn diff /Applications/ghdl will show no differences other than any target addition in translate/ghdldrv/Makefile. Copying the hello world program from the ghdl manual will produce something that causes a segmentation violation if the Stock_Boundary isn't set correctly. I've generated a process based version of hello world using a report statement that doesn't crash. I've also tested this with small chip design of the DES encryption algorithm, that while the model is small does elaborate test bench testing of 291 key/plaintext/ciphertext pairs running over 587 usecs with a 20 ns clock period (with lots of things happening every clock). It performs assertion based verification and I've also checked the output of the model manually with gtkwave. I've also tried the current revision (143) which gets segmentation violations identically to having Stack_Boundary incorrect (even if it is set correctly). I'm pursuing this because I want to be able to release some patches for bugs that have been reported recently. You could note the latest revision (143) compiles and runs an mcode version under Linux. Brian Davis has a temporary patch to allow it to run as a w32 Windows target. It's likely the same bug (deficiency) is expressing itself slightly differently in the w32 and Mac OS X builds. His patch doesn't fix the version built on Mac OS X. This gets us to ghdl-0.27+ on Mac OS X. I'll continue marching upward to find out what changed to cause the segmentation violation at run time. It may be a bit sticky if there's a bunch of compiler dependencies. I might also try a later gnat version to see what happens. I'm fairly confident once I get the current revision running as an mcode version I can build it as a gcc frontend on Mac OS X, it's a matter of capturing build environment, which I could do from compiling gcc under Macports. I'd originally been dancing back and forth between revisions 103 (which builds and runs) and 143 but realized I hadn't tried revision 108 with a known correct Stack_Boundary after picking it as a binary search target previously. Brian's patch increases stack frame size by 8 bytes. I'm guessing if that value was increased for Mac OS X it would run there. We're seeing a basic difference in stack element sizes between the three x86 architectures (w32, Mac OS X and Linux). We could get lucky and find it's one thing that's doing it. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
