On Sat, 2013-12-14 at 15:03 +0100, Joris van Rantwijk wrote: > Hello Brian, Nicolas, > > I have been working on integrating Brian's patches into a GHDL Debian > package based on gcc-4.8. This is coming along nicely, but I have a few > questions.
I will try to answer each. > I am still uncertain about the best way to handle the upstream > situation. > My current approach is to take the latest SVN snapshot from > http://gna.org/projects/ghdl/ as baseline and to add selected patches > from Brian's repository http://sourceforge.net/projects/ghdl-updates/ > as Debian patches. Brian is currently making fast progress with fixing > real, reported bugs in GHDL. This could result in a large number of > Debian patches in my package. > > An alternative is to switch to Brians's sourceforge repository as > upstream baseline. However I don't want to do that unless there is > consensus within the GHDL community that Sourceforge is THE new upstream > repository. David and I are leaning towards Sourceforge, not least because I'm having difficulty with access to the repository on gna.org. I would strongly advise that either you take the Sourceforge repository, or if you must keep gna.org, that you take the entire set of recent patches from Sourceforge as a single step rather than selecting a subset of them. Otherwise there is a danger of building an inconsistent version and reintroducing incompatibilities. > I would love to know Tristan's view on the future of the Gna > repository. Are we in principle still working towards an upcoming > release of GHDL 0.30? While I cannot answer for Tristan, my own view is that 0.30 was approximately SVN r150 (+ OSVVM +/-64 bit patch) and some aspects of it were a dead end. The 4.8 build is sufficiently different that I am calling it 0.31dev at the moment, aiming for a solid 0.31 release. > Finally, some specific comments on the current Sourceforge patch set: > * I have completely dropped which was required > under gcc-4.7 to avoid an internal compiler error on 64 bit. It seems > that this patch is no longer needed with gcc-4.8. Brian, do you agree? On which repository is "changeset ff92a40ea4d9" a searchable item? I don't recognise the number... If you mean this change set https://sourceforge.net/p/ghdl-updates/code/ci/26f177817bffcc140609f5885614f2edb55efb59/ I believe the underlying issue IS still there in the compiler; however that changeset is corrected by later changes to ortho_lang.c, specifically https://sourceforge.net/p/ghdl-updates/code/ci/655b2faf0dc82716e3a13be4d4415a25dc4212c1/ so that both 32 and 64 bit builds work. > * With regard to the Start_Choice function, I'm still using your > original patch which adds a Value parameter to the function. Passing > this context as a parameter seems to me fundamentally cleaner than > passing it through a static variable. I originally thought so, and still would if gcc was the only backend. I reverted that change and localised gcc's new requirement to the gcc interface (specifically ortho_lang.c again) rather than modify the interface to all backends. Currently the only other active backend is the Mcode version (more below); there has apparently also been an experimental LLVM backend which may be worth reconsidering. Anyway I don't want gcc to distort ghdl's architecture unless it's critically important to do so, and the static variable is in line with the way other aspects of the gcc interface have been handled. I'm open to other opinions here, but understand that modifying the interface would involve modifying all (currently both) backends. I didn't understand mcode at all last time (0.30) so I'm lucky I didn't break it accidentally, and I nearly broke it this time. It turns out there is a good case for making the mcode version available even on targets where a gcc version is available. It doesn't have the performance of the gcc version (though in a straight comparison I only found it 20% slower) but it can compile and simulate much larger VHDL designs like gate-level netlists, where the gcc backend (even without optimisation options) takes all the memory you have, starts swapping, takes all the swap space you have and finally falls over with an allocation failure. > * There is an "OSVVM" patch in changeset 5594d173a2d3 wich looks > intrusive and I don't understand its purpose. Could you provide a > reference to a bug report or further information? For the background see www.osvvm.org . ghdl had several bugs including a critical one handling overloaded protected procedures, preventing this Open Source simulator from exploiting the Open Source VHDL Verification Methodology. Bug report was https://gna.org/bugs/?20769 That patch resolved those bugs allowing the VHDL-2002 version of OSVVM to work. There is a lot more to do before ghdl can support the VHDL-2008 version! > My work on the package is available for inspection here: > https://github.com/jorisvr/ghdl_debian > Once it stabilizes, I will upload ghdl_0.30~svn20130213-4 to Debian > mentors. I repeat, I regard 0.31 as the target, and regard everything up to at the first two changesets from yesterday as necessary for a good product. These cover: clean 32 and 64 bit gcc4.8 builds OSVVM clean mcode builds resolve gcc optimisation pass failures add missing 'image and 'value attribute functionality responsible for a slew of bug reports over the years. More recent fixes are less critical and probably easy to apply to either tree. There are a few more to come including (I hope) some fixes for reported Debian bugs. Thanks for your work, I look forward to seeing ghdl back in Debian! Regards, - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
