On Jan 8, 2012, at 00:04, David Koontz wrote: > I'm going to try this on for shock value, then show a light at the end of the > tunnel. > > First, no one is currently actively developing GHDL. There has been a dearth > of volunteers. Tristan is off working hard for living doing Ada coding for > what's probably flight critical applications in aerospace. I should be > working for a living, too. Add to that I can't actually upload a release > image to ghdl.free.fr from outside the free.fr domain, and only critical > fixes are going to get released, making demands on Tristan's time (or > rehosting or forking GHDL). > > Gcc release cycles have been too frequent for one person to keep up with part > time (as you can attest). The implication is that GHDL can't keep up without > more bodies or code contributions flowing back. Today there is one part time > person and people praying for bug fixes.
One of the problems in the code is that there is a serious lack of design documentation. So, the important concepts and reasoning behind implementation choices are stored in grey matter rather than publicly accessible binary form. While this is understandable for a project mostly done by a single person, it makes it increasingly harder for others to join. > Currently the lifetime of the gcc front end version of GHDL is bound by the > ability to compile gcc-4.3.x or otherwise newer version. > > Now for the good news. I recently came across someone doing a VHDL analyzer > and simulator inspired by GHDL, written in C. There is one very interesting > characteristic although the code is being organically grown (incrementally > implemented, meaning potentially doing things over as you add complexity). > It uses the LLVM code generator (back end) which is separable from the front > end, uncoupling some of the forced synchronization like you're noting with > trying to go beyond gcc-4.3.4 and gnat 4.4. The GCC front end is completely separable from the back end. For example, the GNAT front end uses at least 5 different back ends, of which GCC is only one. Actually, we typically support a number of different GCC versions at a time, typically with only a few hundred changed lines between revisions. It is the question if a new project will grow to the relative maturity of GHDL. > > In the LLVM 3.1 release notes there's mention of a gcc-4.6.1 based front end > that implements Ada fully. This new tool adopts LLVM's bitcode library > format preserving the ability I think to do Link Time Optimization (which an > HDL simulator can benefit from) and foreign interfaces. As a long time developer of GNAT, I can say the "fully" part of the claim is dubious. There is a world of difference between a compiler than can bootstrap and build some runnable programs, and a compiler that is fully validated and actually conforming. Anyway, the biggest obstacle in maintaining GHDL is the lack of documentation, both at the code level and at the design level (description of file formats, run time interfaces, generated code models). For any rehosting or other major updates, starting with writing this documentation, through reverse-engineering and study of the code, is the best first step. > I'd suggest GHDL takes a similar path and uses the LLVM back end in the > future, in effect leapfrogging to become up to date. This provides a promise > of the ability to do parallel thread execution at some point, too. This is going to be far more work than updating GHDL for the current GCC. Moreover, once you have done an update to new GCC versions, it gets far easier for future versions, especially if you keep clean interfaces. Parallel execution is a completely separate thing, mostly determined by the design of the run time used for the simulation. It has relatively little to do with the compiler that is being used. Note that there really is no issue of doing parallel compilation, because that is already trivially possible. As the run time is written in Ada, the mechanics of parallel execution are trivially available. I don't know how well the simulation model and algorithms lend themselves to parallelization though. > In lieu of crafting the future there's always an mcode version for Linux and > there's also the issue of VHDL standard compliance, where GHDL isn't fully > VHDL-93 compliant. > > As far as your immediate problem other than Thomas Sailer at the Fedora > Project with the multilib stuff, no. His patches ought to be evaluate fro > inclusion in ghdl. On the surface gnat-4.6 seems separable from multilibs. If I find some time, I'd be interested in helping out with GHDL. I know the Ada compiler very well, and know my way around in the GCC back end. -Geert _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
